HTTP笔记

这部分本来没打算仔细看，后来发现面试的时候会问到我，再稍微看一看。

面试题：在浏览器中输入url地址->显示主页的过程？

1、DNS解析
2、TCP连接
3、发送HTTP请求
4、服务器处理请求并返回HTTP报文
5、浏览器解析并渲染页面
6、结束连接

面试题：各种协议和HTTP协议之间的关系：

1、基础概念

请求和响应报文

客户端发送一个请求报文给服务器，服务器根据请求报文中的信息进行处理，并将处理结果放入响应报文中返回给客户端。

请求报文结构：

第一行包含了请求方法、URL、协议版本；
接着多行是请求首部，每个首部有一个首部名称及对应的值；
一个空行分割首部和内容主体Body
最后是请求的内容主题

响应报文结构：

第一行包含协议版本、状态码及描述，最常见的是200 OK表示请求成功
接下来多行是首部内容
一个空行分割首部和内容主体Body
最后是响应的内容主题

URL

（Uniform Resource Locator，统一资源定位符）
HTTP使用URL来定位资源，URL是URI（Uniform Resource Identifier，统一资源标识符）的子集，URL在URI的基础上增加了定位能力。
URI除了包含URL，还包含URN（Uniform Resource Name，统一资源名称），它只是用来定义一个资源的名称，并不具备定位该资源的能力。

面试题：URI和URL的区别是什么?

URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源。
URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。
它是⼀种具体的 URI，即 URL 可以⽤来标识⼀个资源，而且还指明了如何 locate 这个资源。
URI的作用像身份证号⼀样， URL的作用更像家庭住址⼀样。
URL是⼀种具体的URI，它不仅唯⼀标识资源，而且还提供了定位该资源的信息。

2、HTTP方法

请求报文第一行为请求行，包含方法字段。

GET：用于获取资源，当前网络请求中，绝大部分使用的是GET方法。
HEAD：用于获取报文首部，类似GET，不返回报文实体主体，用于确认URL的有效性及资源更新的日期时间。
POST：传输实体主体，POST主要用来传输数据，GET主要用来获取资源。
PUT：上传文件，自身不带验证机制，任何人都可以上传文件，存在安全问题。
PATCH：对资源进行修改，PUT可以修改资源，但是只能完全替代，PATCH允许部分修改。
DELETE：删除文件，与PUT功能相反，不带验证机制。
OPTIONS：查询支持的方法，查询指定的URL能够指定的方法，返回类似Allow: GET, POST, HEAD, OPTIONS
CONNECT：要求在与代理服务器通信时建立隧道，使用SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。
TRACE：追踪路径，服务器会将通信路径返回给客户端。
发送请求时，在在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。
通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

3、HTTP状态码：

响应报文中第一行为状态行，包含状态码及原因短语，用于告知客户端请求的结果。

1XX信息

**100 Continue：**表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX成功

200 OK
**204 No Content：**请求已成功处理，但是返回响应报文中不含实体的主体部分。通常用于只需要客户端向服务器发送信息，不需要返回数据时使用。
206 Partial Content： 表示客户端进行了范围请求，响应报文包含由Content-Range指定范围的实体内容。

3XX重定向

301 Moved Permanently：永久性重定向
302 Found：临时性重定向
303 See Other：和302有相同功能，但303明确要求客户端应该采用GET方法获取资源。

HTTP协议规定301,302状态下重定向时不允许把POST方法改成GET方法，但是大多数浏览器都会在301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。

304 Not Modified如果请求报文包含一些条件，If-Match等，如果不满足条件则服务器会返回304状态码。
307 Temporary Redirect 临时重定向，与302含义类似，但是307要求浏览器不会把重定向请求的POST方法改成GET方法。

4XX客户端错误

**400 Bad Request ：**请求报文中存在语法错误。

401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。

**403 Forbidden ：**请求被拒绝。

404 Not Found

5XX 服务器错误

500 Internal Server Error：服务器正在执行请求时发生错误。
503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

四、HTTP 首部

通用首部字段

请求首部字段

响应首部字段

实体首部字段

五、具体应用

1、连接管理

1、短连接与长连接

当浏览器访问一个包含多张图片的页面时，除了请求访问的HTML页面资源，还会请求图片资源。
若每进行一次HTTP通信就新建一个TCP连接，开销会很大。

长连接只需要建立一次TCP连接就能进行多次HTTP通信。

HTTP/1.1之前默认短连接，若使用长连接，则使用Connection：Keep-Alive
HTTP/1.1开始默认长连接，若要断开连接，需要客户端或服务器端提出断开，使用Connection：close

2、流水线

默认情况下，HTTP请求按顺序发出，下一个请求只有在当前请求收到响应之后才会被发出。
由于受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线则是在同一条长连接上连续发出请求，而不用等待响应返回，可以减少延迟。

HTTP长连接、短连接：

在HTTP/1.0中默认使用短连接。
也就是说，客户端和服务器每进⾏⼀次HTTP操作，就建立一个连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、 CSS文件等），每遇到这样⼀个Web资源，浏览器就会重新建立⼀个HTTP会话。

⽽从HTTP/1.1起，默认使用长连接，⽤以保持连接特性。
使用长连接的HTTP协议，会在响应头加⼊这⾏代码：Connection:keep-alive
在使⽤长连接的情况下，当⼀个⽹⻚打开完成后，客户端和服务器之间⽤于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使⽤这⼀条已经建⽴的连接。 KeepAlive不会永久保持接，它有⼀个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

2、Cookie

HTTP/1.1引入Cookie保存状态信息，使能处理大量事务。

Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被带上，用于告知服务端两个请求是否来自同一浏览器。~同样会带来性能开销。

1、用途

1、会话状态管理(如用户登录状态、购物车状态等)
2、个性化设置(如用户自定义设置、主题等)
3、浏览器行为跟踪(如跟踪分析用户行为等)

2、创建过程

服务器发送的响应报文中包含Set-Cookie首部字段，客户端得到响应报文后把Cookie内容保存到浏览器中。
客户端之后对同一个服务器发送请求时，会从浏览器中取出Cookie信息并通过Cookie请求首部字段发动给服务器。

3、分类

**会话期Cookie：**浏览器关闭之后会被自动删除，仅在会话期内有效。
**持久性Cookie：**指定过期时间或有效期之后就成为了持久性的Cookie。

4、作用域

Domain 标识指定了哪些主机可以接受 Cookie。如果不指定，默认为当前文档的主机（不包含子域名）。
如果指定了 Domain，则一般包含子域名。
例如，如果设置 Domain=mozilla.org，则 Cookie 也包含在子域名中（如 developer.mozilla.org）。

Path标识指定了主机下哪些路径可以接受Cookie(该URL路径必须存在于请求URL中)。
以字符 %x2F ("/") 作为路径分隔符，子路径也会被匹配。
例如，设置Path = /docs，/docs、/docs/Web/、/docs/Web/HTTP都会被匹配。

5. JavaScript脚本
浏览器通过document.cookie属性可以创建新的Cookie，也可通过该属性访问非HttpOnly标记的Cookie。

HttpOnly
标记为HttpOnly的Cookie不能被JavaScript脚本调用。可以一定程度上避免XSS攻击。
跨站脚本攻击 (XSS) 常常使用 JavaScript 的 document.cookie API 窃取用户的 Cookie 信息。

6、Secure
标记为Secure的Cookie只能通过被HTTPS协议加密过的请求发送给服务端。
即便设置了Secure标记，敏感信息也不应该通过Cookie传输，因为Cookie存在固有的不安全性，Secure无法提供确实的安全保障。

7、Session

可以使用Session 将用户信息存储在服务器端，相较于Cookie更安全。
Session可以存储在服务器上的文件、数据库或者内存中。也可以存储在Redis内存型数据库中，效率更高。

使用Session维护用户登录状态的过程：
1、用户登录时，用户提交包含用户名和密码的表单，放入HTTP请求报文中；
2、服务器验证用户名、密码，正确则将用户信息存入Redis中，在Redis中的Key成为Session ID；
3、服务器返回的响应报文的Set-Cookie首部字段包含这个Session ID，客户端收到响应报文后将该Cookie值存入浏览器；
4、客户端之后对同一个服务器进行请求时会包含该Cookie值，服务器收到之后取出Session ID，从Redis中取出用户信息，继续之前的操作。

Session ID的安全性问题：不能让它被恶意攻击者轻易获取，需要经常重新生成 Session ID
例如转账时，除了Session管理用户状态，还需要对用户进行重新验证：重输密码、短信验证码等。

浏览器禁用 Cookie
此时无法使用 Cookie 来保存用户信息，只能使用 Session。除此之外，不能再将 Session ID 存放到 Cookie 中，而是使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。

面试题：Cookie的作用是什么？Cookie和Session有什么区别？

Cookie和Session都是用来跟踪浏览器用户身份的会话方式。
Cookie一般用来保存用户信息。
Session的主要作用是通过服务端记录用户的状态。

** Cookie与Session对比**

0、Cookie数据保存在客户端（浏览器端），Session数据保存在服务器端。
1、存取方式上： Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
2、隐私策略上： Cookie 存储在浏览器中，对客户是可见的，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie 值进行加密，然后在服务器进行解密； Session存储在服务器上，不存在敏感信息泄漏的风险。
3、服务器压力的不同： 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。Cookie保管在客户端，不占用服务器资源。
4、有效期的不同： 例如Google的登录信息长期有效，可运用Cookie实现这种效果，只需要设置Cookie的过期时间为一个很大的数字；而Session依赖于名为JSESSIONID的Cookie，Session不能完成信息永世有效的效果，若设置Session的超时时间过长，累计Session过多会导致内存溢出。
5、浏览器支持的不同： Cookie需要客户端浏览器支持。假如客户端禁用了Cookie，或者不支持Cookie，则会话跟踪会失效。需要运用Session以及URL地址重写，将 Session ID 作为 URL 的参数进行传递。
6、跨域支持上的不同：
Cookie支持跨域名访问，例如将domain属性设置为“.biaodianfu.com”，则以“.biaodianfu.com”为后缀的一切域名均能够访问该Cookie。Session则不会支持跨域名访问，Session仅在他所在的域名内有效。

面试题：HTTP是不保存状态的协议,如何保存用户状态?

HTTP 是⼀种不保存状态，即无状态（stateless）协议。
也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存⽤户状态呢？

Session 机制的存在就是为了解决这个问题， Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个⽤户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（⼀般情况下，服务器会在⼀定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。

在服务端保存 Session 的⽅法很多，最常⽤的就是内存和数据库(⽐如是使⽤内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？⼤部分情况下，我们都是通过在 Cookie 中附加⼀个 Session ID 的方式来跟踪。

Cookie 被禁用怎么办?
最常⽤的就是利用 URL 重写把 Session ID 直接附加在URL路径的后⾯。

3、缓存

优点

1、缓解服务器压力
2、降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存速度更快。
	缓存服务器在地理位置上可能比源服务器来得近，例如浏览器缓存。

实现方法：

1、让代理服务器进行缓存
2、让客户端浏览器进行缓存

HTTP/1.1通过Cache-Control首部字段来控制缓存。

1、禁止进行缓存：
	no-store指令规定不能对请求或响应的任何一部分进行缓存。
2、强制确认缓存：
	no-cache指令规定缓存服务器要先向源服务器验证缓存资源的有效性，
	只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应
3、私有缓存和公共缓存
	private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。
	public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。
4、缓存过期机制
	max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。
	max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。
		Cache-Control: max-age=31536000
	Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。
		Expires: Wed, 04 Jul 2012 08:26:05 GMT
		
	在 HTTP/1.1 中，会优先处理 max-age 指令；
	在 HTTP/1.0 中，max-age 指令会被忽略掉。

缓存验证：

ETag: "82e22293907ce725faf67773957acd12"

ETag首部字段，是资源的唯一标识。
URL不能唯一表示资源，例如http://www.google.com/ 有中文和英文两个资源，只有 ETag 才能对这两个资源进行唯一标识。

可以将缓存资源的ETag值放入If-None-Match首部，服务器收到请求后，判断缓存资源的ETag值和资源的最新ETag值是否一致，如果一致则表示缓存资源有效，否则返回304 Not Modified。

Last-Modified首部资源也可以用于缓存验证，它包含在源服务器发送的响应报文中，指示源服务器对资源的最后修改时间。但它是一种弱校验器，因为只能精确到一秒，通常作为ETag的备用方案。
如果响应首部字段里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。
服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 OK。
如果请求的资源从那时起未经修改，那么返回一个不带有实体主体的 304 Not Modified 响应报文。

4、内容协商

通过内容协商返回最合适的内容，如根据浏览器的默认语言选择返回中文界面还是英文界面。

1、服务端驱动型内容协商

客户端设置特定的HTTP首部字段，如Accept、Accept-Charset、Accept-Encoding、Accept-Language，服务器根据这些字段返回特定的资源。
存在问题：

1、服务器很难知道客户端浏览器的全部信息；
2、客户端提供的信息相当冗长(HTTP/2协议的首部压缩机制缓解)，且存在隐私风险(HTTP指纹识别技术)；
3、给定的资源需要返回不同的展现形式，共享缓存的效率会降低，服务端的实现会越来越复杂。

2、代理驱动型内容协商

服务器返回 300 Multiple Choices 或者 406 Not Acceptable，客户端从中选出最合适的那个资源。

3、Vary

在使用内容协商的情况下，只有当缓存服务器中的缓存满足内容协商条件时，才能使用该缓存，否则向源服务器请求该资源。

如，一个客户端发送包含Accept-Language首部字段的请求后，源服务器返回的响应包含 Vary：Accept-Language内容，缓存服务器对这个响应进行缓存之后，在客户端下一次访问同一个URL资源，且Accept-Language与缓存中的对应的值相同时才会返回该缓存。

5、内容编码

内容编码将实体主体进行压缩，从而减少传输的数据量。
常用的内容编码：gzip、compress、deflate、identity

浏览器发送 Accept-Encoding 首部，其中包含所支持的压缩算法，及各自的优先级。
服务器从中选择一种，使用该算法对响应的信息主体进行压缩，并且发送Content-Encoding首部告知浏览器选择哪种算法。由于该内容协商过程是基于编码类型来选择资源的展现形式的，响应报文的 Vary 首部字段至少要包含 Content-Encoding。

6、范围请求

如果网络出现中断，服务器只发送了一部分数据，范围请求可以使客户端只请求服务器未发送的部分数据，避免服务器重新发送所有数据。

1、Range
在请求报文中添加Range首部字段指定请求的范围。
请求成功的话服务器返回的响应包含** 206 PartialContent 状态码**。

2、Accept-Ranges
响应首部字段Accept-Ranges 用于告知客户端是否能处理范围请求，可以处理–bytes，否则使用none。

3、响应状态码

请求成功的情况下，服务器返回206 Partial Content状态码。
请求范围越界的情况下，服务器会返回 416 Requested Range Not Satisfiable 状态码。
不支持范围请求的情况下，服务器会返回 200 OK 状态码。

7、分块传输编码

Chunked Transfer Encoding，可以把数据分割成多块，让浏览器逐步显示页面。

8、多部分对象集合

一份报文主体内可含有多种类型的实体同时发送，每个部分之间用 boundary 字段定义的分隔符进行分隔，每个部分都可以有首部字段。

9、虚拟主机

HTTP/1.1 使用虚拟主机技术，使得一台服务器拥有多个域名，并且在逻辑上可以看成多个服务器。

10、通信数据转发

1、代理

代理服务器接收客户端的请求，并且转发给其它服务器。

使用代理服务器的主要目的：缓存、负载均衡、网络访问控制、访问日志记录。
代理服务器可分为正向代理和反向代理两种：
1、正向代理：用户可以察觉正向代理的存在。
2、反向代理：一般位于内部网络中，用户察觉不到。

2、网关

网关服务器会将HTTP转化为其它协议进行通信，从而请求其它非HTTP服务器的服务。

3、隧道

使用SSL等加密手段，在客户端和服务器之间建立一条安全的通信线路。

六、HTTPS

HTTP存在安全性问题：
1、使用明文进行通信，内容可能会被窃听。
2、不验证通信方的身份，通信方的身份可能遭遇伪装。
3、无法证明报文的完整性，报文可能遭到篡改。

HTTPS使用了隧道进行通信：让HTTP先和SSL(Secure Sockets Layers) 通信，再由SSL和TCP通信。
通过使用SSL，HTTPS具有了加密(防窃听)、认证（防伪装）和完整性保护（防篡改）。

1、加密

1、对称秘钥加密

对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。
优点：运算速度快。
缺点：无法安全地将密钥传输给通信方。

2、非对称秘钥加密

非对称秘钥加密，又称公开秘钥加密（Public-Key Encryption），加密和解密使用不同的密钥。
公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥后，可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥进行解密，就能判断这个签名是否正确。

优点：可以更安全地将公开密钥传输给通信发送方；
缺点：运算速度慢。

3、HTTPS采用的加密方式

采用混合的加密机制：
1、使用非对称密钥加密方式，传输对称密钥加密方式所需要的Secret Key，保证安全性。
2、获取到Secret Key之后，再使用对称加密方式进行通信，从而保证效率。

2、认证

通过使用证书对通信方进行认证。
数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

服务器的运营人员向CA提出公开密钥的申请，CA在判明提出申请的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

进行HTTPS通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥后，先使用数字签名进行验证，如果验证通过可以开始通信。

3、完整性保护

SSL提供报文摘要功能来进行完整性保护。

HTTP也提供MD5报文摘要功能，但不是安全的。
如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

HTTPS的报文摘要功能是安全的，结合了加密和认证两个操作。
加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

4、HTTPS的缺点

1、需要进行加密解密等过程，速度更慢；
2、需要支付证书授权的高额费用。

面试题：HTTP 和 HTTPS 的区别？

1、端口 ： HTTP的URL由“http://”起始且默认使⽤端⼝80，⽽HTTPS的URL由“https://”起始且默认使⽤端⼝443。
2、安全性和资源消耗： HTTP协议运⾏在TCP之上，所有传输的内容都是明⽂，客户端和服务器端都⽆法验证对⽅的身份。 HTTPS是运⾏在SSL/TLS之上的HTTP协议， SSL/TLS 运⾏在TCP之上。所有传输的内容都经过加密，加密采⽤对称加密，但对称加密的密钥⽤服务器⽅的证书进⾏了⾮对称加密。所以说， HTTP 安全性没有 HTTPS⾼，但是 HTTPS 比HTTP耗费更多服务器资源。

对称加密：密钥只有⼀个，加密解密为同⼀个密码，且加解密速度快，典型的对称加密算法有DES、 AES等；
**非对称加密：**密钥成对出现（且根据公钥⽆法推知私钥，根据私钥也⽆法推知公钥），加密解密使⽤不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的⾮对称加密算法有RSA、 DSA等。

七、HTTP/2.0

1、HTTP/1.x的缺陷：

HTTP/1.x实现简单是以牺牲性能为代价的：
1、客户端需要使用多个连接才能实现并发和缩短延迟；
2、不会压缩请求和响应首部，从而导致不必要的网络流量；
3、不支持有效的资源优先级，致使底层TCP连接的利用率低下。

2、二进制分帧层：

HTTP/2.0将报文分成HEADERS帧和DATA帧，都是二进制格式的。

在通信过程中，只会有一个TCP连接存在，承载了任意数量的双向数据流（Stream）。
1、一个数据流Stream都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
2、消息Message是与逻辑请求或响应对应的完整的一系列帧。
3、帧Frame是最小的通信单位，来自不同数据流的帧可以交错发送，然后根据每个帧头的数据流标识符重新组装。

3、服务端推送：

HTTP/2.0在客户端请求一个资源时，会把相关的资源一起发给客户端，客户端不需要再次发起请求。
如：客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。

4、首部压缩：

HTTP/1.1 的首部带有大量信息，而且每次都要重复发送。
HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。
不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。

面试题：HTTP 1.0和HTTP 1.1的主要区别是什么?

1、HTTP/1.1默认长连接 :
在HTTP/1.0中，默认使⽤的是短连接，也就是说每次请求都要重新建⽴⼀次连接。
HTTP 是基于TCP/IP协议的,每⼀次建⽴或者断开连接都需要三次握⼿四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持⼀个长连接，可以用一个长连接来发多个请求。
HTTP 1.1起，默认使⽤长连接 ,默认开启Connection： keep-alive。
HTTP/1.1的持续连接有流水线和非流水线两种方式 。流⽔线⽅式是客户在收到HTTP的响应报文之前就能接着发送新的请求报⽂。与之相对应的非流水线方式是客户在收到前⼀个响应后才能发送下⼀个请求。
2、错误状态响应码 :
在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发⽣冲突；
410（Gone）表示服务器上的某个资源被永久性的删除。
3、缓存处理 :
在HTTP1.0中主要使用header⾥的If-Modified-Since,Expires来做为缓存判断的标准， HTTP1.1则引⼊了更多的缓存控制策略例如Entity tag， If-Unmodified-Since, If-Match,If-None-Match等更多可供选择的缓存头来控制缓存策略。
4、带宽优化及网络连接的使⽤ :
HTTP1.0中，存在⼀些浪费带宽的现象，例如客户端只是需要某个对象的⼀部分，⽽服务器却将整个对象送过来了，并且不⽀持断点续传功能，
HTTP1.1则在请求头引⼊了range头域，它允许只请求资源的某个部分，即返回码是206（PartialContent），这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。

HTTP/1.1新特性：

1、默认是长连接；
2、支持流水线；
3、支持同时打开多个TCP连接；
4、支持虚拟主机；
5、新增状态码100；
6、支持分块传输编码；
7、新增缓存处理指令max-age。

面试题：GET和POST的区别：

1、GET是获取数据的，而POST是提交数据的。
2、GET用于获取信息，是无副作用的，是幂等的，可缓存；POST用于修改服务器上的数据，有副作用，非幂等，不可缓存。

1、作用上： GET用于获取资源，POST用于传输实体主体。

2、**参数上：**二者都能使用额外的参数，但是GET的参数以查询字符串出现在URL中，POST的参数存储在实体主体中。
----从传输的角度来讲，二者都是不安全的。因为HTTP在网络上是明文传输的，想安全传输，使用HTTPS。
URL只支持ASCII码，GET的参数中如果存在中文字符就需要先进行编码。POST参数支持标准字符集。

3、安全：------这里的安全指不改变服务器的状态
安全的HTTP方法不会改变服务器的状态，只是可读的。
GET方法是安全的，POST不是。因为POST的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功后，服务器可能把这个数据存储到数据库中，状态也就发生了改变。
安全的方法：GET、HEAD、OPTIONS
不安全的方法：POST、PUT、DELETE

4、**幂等性：**同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。
------换句话说就是，幂等方法不应该具有副作用（统计用途除外）。
所有的安全方法都是幂等的。
正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。

5、可缓存：
如果要对响应进行缓存，需要满足以下：
1、请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
2、响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
3、响应报文的 Cache-Control 首部字段没有指定不进行缓存。

6、XMLHttpRequest

XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。
它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。
这使得网页只更新一部分页面而不会打扰到用户。
XMLHttpRequest 在 AJAX 中被大量使用。

1、在使用 XMLHttpRequest 的 POST 方法时，浏览器会先发送 Header 再发送 Data。但并非所有浏览器会这样，火狐就不会。
2、而 GET 方法 Header 和 Data 会一起发送。