HTTP/HTTPS

说明

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用、所以支持HTTP就一定支持TCP传输。常见的请求方式有get和post，web服务。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”

优点

1.基于应用级的接口使用方便
2.要求的开发水平不高，容错性强

适用场景

公司OA服务，互联网服务

缺点

1.传输速度慢，数据包大。
2.如实现实时交互，服务器性能压力大
3.数据传输安全性差

HTTP协议

1、（超文本传输协议，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。
2、所有的WWW文件都必须遵守这个标准。
3、设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。
4、是用于从WWW服务器传输超文本到本地浏览器的传输协议。
5、默认使用80端口，HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。

和TCP关系

1、HTTP协议和TCP协议是不冲突的，HTTP定义在七层协议中的应用层，TCP解决的是传输层的逻辑。
2、HTTP使用TCP而不是UDP的原因在于（打开）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。
3、HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性。如TCP建立连接时三次握手有1.5个RTT（round-trip time）的延迟，为了避免每次请求的都经历握手带来的延迟，应用层会选择不同策略的http长链接方案。又如TCP在建立连接的初期有慢启动（slow start）的特性，所以连接的重用总是比新建连接性能要好。

特点

HTTP连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

发展历史

• HTTP1.0
  超文本传输协议是WEB服务器用来处理服务器和客户端之间数据流的协议。基于TCP协议、作用于应用层。
  HTTP 协议老的标准是HTTP/1.0，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

  1、会造成了一些性能上的缺陷，例如，一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的图像标签后，浏览器将根据标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。显 然，访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应，每次请求和响应都需要建立一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件，CSS文件等内容时，也会出现类似上述的情况
  2、带宽和延迟也是影响一个网络请求的重要因素。在网络基础建设已经使得带宽得到极大的提升的当下，大部分时候都是延迟在于响应速度。
  

• HTTP1.1
  为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

  1、一个包含有许多图像的网页文件的多个请求和应答可以在一个>连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
  2、在http1.1，request和reponse头中都有可能出现一个connection的头，此header的含义是当client和server通信时对于长链接如何进行处理。
  3、在http1.1中，client和server都是默认对方支持长链接的， 如果client使用http1.1协议，但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。
  4、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缓存等机制相关的请求头和响应头。HTTP/1.0不支持文件断点续传，<code>RANGE:bytes</code>是HTTP/1.1新增内容，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。<code>RANGE:bytes=XXXX</code>表示要求服务器从文件XXXX字节处开始传送，这就是我们平时所说的断点续传！
  

请求方式

格式	说明
GET	请求获取Request-URI所标识的资源
POST	在Request-URI所标识的资源后附加新的数据
HEAD	请求获取由Request-URI所标识的资源的响应消息报头
PUT	请求服务器存储一个资源，并用Request-URI作为其标识
DELETE	请求服务器删除Request-URI所标识的资源
TRACE	请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT	保留将来使用
OPTIONS	请求查询服务器的性能，或者查询与资源相关的选项和需求

请求状态

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值

格式	说明
1xx	指示信息--表示请求已接收，继续处理
2xx	成功--表示请求已被成功接收、理解、接受
200	成功----服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页
201	已创建---请求成功并且服务器创建了新的资源
202	已接受----服务器已接受请求，但尚未处理
3xx	重定向--要完成请求必须进行更进一步的操作
300	针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择
301	永久移动---请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置
302	临时移动---服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
303	查看其他位置---请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码
304	未修改----自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容
4xx	客户端错误--请求有语法错误或请求无法实现
401	错误请求---服务器不理解请求的语法
401	未授权---请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应
403	禁止 ---服务器拒绝请求
404	未找到----服务器找不到请求的资源
5xx	服务器端错误--服务器未能实现合法的请求
500	服务器内部错误 --服务器遇到错误，无法完成请求
501	尚未实施---服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码
502	错误网关---服务器作为网关或代理，从上游服务器收到无效响应
503	服务不可用---服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态

移动app如何实现长链接

• 基于tcp的长链接

  现在越来越多的移动端app都会建立一条自己的长链接通道，通道的实现是基于tcp协议。基于tcp的socket编程技术难度相对复杂很多，而且需要自己制定协议，但带来的回报也很大。信息的上报和推送变得更及时，在请求量爆发的时间点还能减轻服务器压力（http短连接模式会频繁的创建和销毁连接）。不止是IM app有这样的通道，像淘宝这类电商类app都有自己的专属长连接通道了。现在业界也有不少成熟的方案可供选择了，google的protobuf就是其中之一。
  

• http long-polling（推送）

  客户端在初始状态就会发送一个polling（轮寻）请求到服务器，服务器并不会马上返回业务数据，而是等待有新的业务数据产生的时候再返回。所以连接会一直被保持，一旦结束马上又会发起一个新的polling请求，如此反复，所以一直会有一个连接被保持。服务器有新的内容产生的时候，并不需要等待客户端建立一个新的连接。做法虽然简单，但有些难题需要攻克才能实现稳定可靠的业务框架。和传统的http短链接相比，长连接会在用户增长的时候极大的增加服务器压力，移动端网络环境复杂，像wifi和4g的网络切换，进电梯导致网络临时断掉等，这些场景都需要考虑怎么重建健康的连接通道。这种polling的方式稳定性并不好，需要做好数据可靠性的保证，比如重发和ack机制（ACK是一个对数据包的确认，当正确收到数据包后，接收端会发送一个ACk给发送端，里面会说明对那个数据包进行确认，每个数据包里都会有一个序列号，如果收到的数据包有误，或错序，还会申请重发，NAK是一个否定的回答，ACK是确定回答，这样保证数据的正确传输）。polling的response有可能会被中间代理cache住，要处理好业务数据的过期机制。long-polling方式还有一些缺点是无法克服的，比如每次新的请求都会带上重复的header信息，还有数据通道是单向的，主动权掌握在server这边，客户端有新的业务请求的时候无法及时传送
  

• http streaming

  同long-polling不同的是，server并不会结束初始的streaming请求，而是持续的通过这个通道返回最新的业务数据。显然这个数据通道也是单向的。streaming是通过在server response的头部里增加”Transfer Encoding: chunked”来告诉客户端后续还会有新的数据到来。除了和long－polling相同的难点之外，streaming还有几个缺陷：有些代理服务器会等待服务器的response结束之后才会将结果推送到请求客户端。对于streaming这种永远不会结束的方式来说，客户端就会一直处于等待response的过程中。业务数据无法按照请求来做分割，所以客户端每收到一块数据都需要自己做协议解析，也就是说要做自己的协议定制。streaming不会产生重复的header数据。
  

• web socket

  WebSocket和传统的tcp socket连接相似，也是基于tcp协议，提供双向的数据通道。WebSocket优势在于提供了message的概念，比基于字节流的tcp socket使用更简单，同时又提供了传统的http所缺少的长连接功能。不过WebSocket相对较新，2010年才起草，并不是所有的浏览器都提供了支持。各大浏览器厂商最新的版本都提供了支持。
  

HTTP2.0

• 多路复用 (Multiplexing)

  多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一，拿 Twitter 为例，[http://twimg.com](http://twimg.com)，目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。
  

• 二进制分帧

  HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码 ，其中 HTTP1.x 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。HTTP/2 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。在过去， HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我调谐，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。这种单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大；而且由于 TCP 连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少,使拥塞和丢包恢复速度更快。
  

• 首部压缩（Header Compression）

  HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积小了，在网络上传输就会更快。
  

服务端推送（Server Push）

服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务器很可能会响应主页内容、logo 以及样式表，因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源，不过与之相比，服务器推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。

HTTPS

HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全。为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。现在的HTTPS都是用的TLS协议，但是由于SSL出现的时间比较早，并且依旧被现在浏览器所支持，因此SSL依然是HTTPS的代名词。

WWW

• WWW是环球信息网的缩写，（亦作“Web”、“WWW”、“'W3'”，英文全称为“World Wide Web”）。
  中文名字为“万维网”，"环球网"等，常简称为Web。
• 万维网联盟（英语：World Wide Web Consortium，简称W3C），又称W3C理事会。
• 万维网并不等同互联网
  万维网只是互联网所能提供的服务其中之一，是靠着互联网运行的一项服务。

超文本

• 超文本除了基础的文本信息、还涵盖了诸如图片、视频、音频等其他资源。
  其实已经发展为超媒体、但习惯上还是叫超文本。
• 超一个超文本由多个信息源链接而成、该文档除了基本的信息之外、还可以有指向信息集合中其他文本的指针（跳转）。
• 超文本的主要格式为HTML。
• 超文本传输协议是WEB服务器用来处理服务器和客户端之间数据流的协议。基于TCP协议、作用于应用层。

类型	说明
http	超文本传输协议资源
https	用安全套接字层传送的超文本传输协议
ftp	文件传输协议
mailto	电子邮件地址
file	当地电脑或网上分享的文件
news	Usenet新闻组
gopher	Gopher协议
telnet	Telnet协议

URL

URL把信息编码成一个字符串、称为统一资源定位(Uniform Resource Locator,URL)。 URL被冒号和斜杠分隔成三个部分：协议、计算机名、文档名。

• protocol
  访问文档所采用的协议名
• computer_name
  文档所在的计算机域名
• port
  协议端口号（可选）
• document_name
  指定计算机上的文件名、包括路径和文件名

工作模式

1552225-6d3f1edd84f90803.png

• 客户端在接收到用户指令后、将打开与服务器相连的TCP连接的80端口（默认是80端口、也可以更改）、然后在此连接上发送相应的请求命令。
• 服务器在接收到请求命令后、对其作出相应的处理后、将其处理的结果以应答消息返回到客户端、并关闭此次TCP连接。

HTTP协议特点

• 支持客户/服务器模式
• 简单快速
  客户向服务器请求服务时、只需要传送请求方法和路径。请求方法常用GET、HEAD、POST。每种方法规定了客户与服务器联系类型的不同。由于HTTP协议简单、使得HTTP服务器的程序规模小、通信速度快。
• 灵活
  HTTP允许传输任意类型的对象。正在传输的类型由Content-Type加以标记。
• 无连接
  HTTP协议每次只能处理一个请求。服务器处理完客户需求并且客户收到应答之后、即断开连接。
• 无状态
  HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。它并不会记录同一个客户端之前所做了什么动作。

HTTP的请求和应答

1552225-36eb84711f865618.png
1552225-487b369c74feb267.png

其中第一行是请求行。<method>是请求方法、URI是请求资源的统一资源标识、<HTTP-version>是协议版本号。余下的分别是报文头(请求头)、报文体(请求体)。

1552225-eab698969fb2c955.png

常见三种方式的请求

• GET请求

  
  1552225-a1457a31a79644b0.png

• HEAD请求
  类似GET请求、但服务器只返回对应资源的首部信息。

• POST请求
  用来负责数据的发送。应用于电子邮件、表格等等。需要提供报文体以及报文长度。

  
  1552225-14f0c71c7fd86fe9.png

• 应答消息
  与请求消息类似、分为消息头和主体两部分、中间以一行空白隔开。
  第一部分是应答头：以状态行开头（http版本、状态编码、原因短语）、跟随表达应答细节着首部字段。
  如果有与应答有关的数据体、放在body(应答体)部分。

  
  1552225-77d2c7ec9c2af256.png

• 请求行

  POST /api/tool/getAreaList HTTP/1.1
    第一部分POST是请求方式 常见的就GET 和 POST（Method）
    第二部分/api/tool/getAreaList是请求的资源路径
    第三部分HTTP/1.1是请求的协议版本 (Protocol)
  

• 请求头

  Host www.baidu.com
  Content-Type application/x-www-form-urlencoded
  Accept */*
  User-Agent ETI/1.0.0 (iPhone; iOS 11.4; Scale/3.00)
  Accept-Language zh-Hans-CN;q=1
  Content-Length 75
  Accept-Encoding gzip, deflate
  Connection keep-alive
  Host： 访问的主机名
  Content-Type：客户端发送的数据类型
  Accept: 客户端所能接收的数据类型，/表示任意类型
  User-Agent: 客户端的类型，客户端的软件环境
  Accept-Language: 客户端的语言环境
  Content-Length:请求中内容的大小。这个大小是包含了内容编码的，比如上面请求是采用gzip压缩，那么Content-Length就是压缩后的大小
  Accept-Encoding: gzip // 客户端支持的数据压缩格式
  Connection：告诉服务器，请求完成后是关闭还是保持链接
  

• Content-Type

  application/x-www-form-urlencoded
      数据被编码为名称/值对。这是标准的编码格式。它会将表单内的数据转换为键值对，比如,name=12&age = 18
  multipart/form-data
      它会将请求表表单中的每条数据处理为一条消息，以标签为单元，用分隔符分开。既可以上传键值对，也可以上传文件。当上传的字段是文件时，会有Content-Type来表名文件类型；content-disposition，用来说明字段的一些信息；由于有boundary隔离，所以multipart/form-data既可以上传文件，也可以上传键值对，它采用了键值对的方式，所以可以上传多个文件
  text/plain
      数据以纯文本形式(text/json/xml/html)进行编码，其中不含任何控件或格式字符。(RAW)
  
  注意：
      1.form的enctype属性为编码方式，常用有两种：application/x-www-form-urlencoded和multipart/form-data，默认为application/x-www-form-urlencoded。
      2.当请求方式为GET时候，浏览器用x-www-form-urlencoded的编码方式把form数据部分转换拼接成一个字符串（例如：name1=value1&name2=value2...），然后把这个字符串追加到url后面，用?分割，加载这个新的url
      3.当请求方式为POST的时候，浏览器把form数据封装到body中，发送到服务端。 如果没有type=file的控件，用默认的application/x-www-form-urlencoded就可以了。 但是如果有type=file的话，就要用到multipart/form-data了
      4.Content-Type类型是multipart/form-data，浏览器会把整个表单以控件为单位分割，并为每个部分加上Content-Disposition(form-data或者file),Content-Type(默认为text/plain),name(控件name)等信息，并加上分割符(boundary)。
  

• Accept-Encoding
  在Http中，可以采用gzip编码方式，对body内容进行编码，来从而达到对内容压缩的方式。

  1.首先客户端发送request给服务端, request 中有Accept-Encoding,告诉服务端数据采用gzip编码压缩
  2.接着服务端接到request后， 生成原始的Response, 其中有  原始的Content-Type和Content-Length
  3.然后通过服务端通过Gzip，来对Response进行编码， 编码后header中有Content-Type和Content-Length(压缩后的大小)， 并且增加了Content-Encoding:gzip. 然后把Response发送给客户端
  4.最后客户端接到Response后，会根据Content-Encoding来对Response 进行解码。 获取到原始response后，再根据数据类型进行解析
  
  注意：
      gzip:表明实体采用GNU zip编码
      compress:表明实体采用Unix的文件压缩程序
      deflate表明实体是用zlib的格式压缩的
      identity表明没有对实体进行编码。当没有Content-Encoding header时， 就默认为这种情况
      gzip, compress, 以及deflate编码都是无损压缩算法，用于减少传输报文的大小，不会导致信息损失。 其中gzip通常效率最高， 使用最为广泛。
  

• Connection
  HTTP协议采用“请求(request)-应答(response)”模式，当Connection为非KeepAliv时，每次请求/应答客户端和服务端都要新建一个连接，完成请求应答之后立即断开连接（此时HTTP协议为无连接的协议）；当使用Keep-Alive（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服 务器端的连接具有持续有效性，当出现对服务端的后继请求时，Keep-Alive功能避免了建立或者重新建立与服务端的连接，避免了建立/释放连接的开销，它更高效，性能更高

    在http 1.0版本中Keep-Alive默认是关闭的，需要在http头加入Connection: Keep-Alive，才能启用Keep-Alive；http 1.1中默认启用Keep-Alive，如果加入Connection: close，才关闭。目前大部分浏览器都是用http1.1协议，也就是说默认都会发起Keep-Alive的连接请求了
  

• 服务端向客户端返回响应结果所包含的内容

  响应行
      HTTP/1.1 200 OK
      第一部分HTTP/1.1 表示HTTP协议版本号
      第二部分200 状态码
      第三部分OK 状态英文名称
  响应头
      Server: nginx/1.12.2
      Date: Thu, 16 Aug 2018 06:26:21 GMT
      Content-Type: application/json;charset=utf-8
      Transfer-Encoding: chunked
      Connection: keep-alive
      X-Powered-By: PHP/7.2.8
      Content-Encoding: gzip
      Server:服务器类型
      Date:返回响应的时间
      Content-Type:返回的数据类型
      Transfer-Encoding:数据传送的方式
      Connection:连接方式
      X-Powered-By:是用何种语言或框架编写
      Content-Encoding: gzip // 服务端对数据的压缩格式
  

HTTP/HTTPS的区别

• 更加多的请求头和响应头
  HTTP1.0没有host的字段

  1、在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
  2、身份认证、状态管理和Cache缓存等机制相关的请求头和响应头
  

• 持续连接（PersistentConnection）

  1、HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection.
  2、HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。
  3、keep-alive timeout时间
        a).keep-alive并不是免费的午餐，长时间的TCP连接容易导致系统资源无效占用，配置不当的keep-alive 有时比重复利用连接带来的损失还更大；因此，正确地设置keep-alive timeout时间非常重要。
        b).在没有设置keepalive_timeout的情况下，一个socket资源从建立到真正释放所需要经过的时间是：建立TCP连接（三次握手）+传送http请求+脚本指向+传送http响应+关闭TCP连接（四次挥手）+主动关闭的一方进入TIME_WAIT的2MSL等待时间；
        c). 当设定了keepalive_timeout时间之后，一个socket由建立到释放所需要经过的时间是：TCP建立连接（三次握手）+（最后一次响应 - 第一次请求时间）+TCP关闭连接（四次挥手）+2MSL；
  

  也就是说，当使用keep-alive机制的时候，当一次请求-响应结束之后，这个连接还会继续维持上keepalive_timeout时间，如果在这 个时间内client端还有请求发过来，那么server端会继续处理给予响应，如果keepalive_timeout时间计时结束后，就会进入TCP 释放连接的阶段，因此也就会结束掉这次通信；

• 请求的流水线（Pipelining）

  1、在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠，多个请求和响应可以同时进行。
  2、例如:一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
  3、HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。这也叫做队首阻塞。
  

• 状态码100(Continue)
  HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

• 断点续传
  HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。RANGE:bytes=XXXX表示要求服务器从文件XXXX字节处开始传送，断点续传。

多路复用

在HTTP1.1中虽然允许并行发送请求、但服务器的响应不允许多个错发送（多路复用），只能等待一个响应完全返回后，下一个响应才能发送，无论下一个响应是否早于前一个响应完成处理，这也叫做队首阻塞。

• HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP1.1大了好几个数量级。
• 当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
• TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。

多路复用的原理

基于二进制分帧层，HTTP 2.0可以在共享TCP连接的基础上，同时发送请求和响应。HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发送出去，最后在另一端根据流ID和首部将它们重新组合起来。