【HTTP】HTTP协议知识点
HTTP协议简介
HTTP（超文本传输协议：HyperText Transfer Protocol）是互联网中最广泛使用的一种通信协议，它允许将超文本标记语言（HTML）文档从WEB服务器传送到客户端的浏览器上，HTTP协议也是做WEB开发的基础，每个WEB开发者都应该了解。我们下面先了解下HTTP协议发展的历史。
HTTP协议发展历史
HTTP协议由1990年提出，经过几年的发展和使用，得到了不断的完善和扩展。
HTTP协议发展时间线
1. HTTP/0.9（1991年）：
是HTTP协议第一个协议，不过比较简单，只有一个GET命令用于获取文件，没有请求头（HEADER）。只能传输HTML格式数据，JSON，XML是不支持的。
第一个定稿的HTTP版本
作者：nickcau
链接：http://www.imooc.com/article/266160
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
第一个定稿的HTTP版本
作者：nickcau
链接：http://www.imooc.com/article/266160
来源：慕课网
本文首次发布于慕课网 ，转载请注明出处，谢谢合作
2. HTTP/1.0（1996年）：
相较于0.9版本非常健全了。规定了http请求由请求头，请求体，对应的还有响应头，响应体。除了GET命令，还增加了POST，HEAD等命令。
3. HTTP/1.1（1997年）：
增加了一些功能，比如管道，持久连接connection：keep-alive，之前版本http请求在请求一次完成后就断开，不能够持久连接。有了keep-alive就可以复用之前的连接，减少因为TCP连接导致的性能损耗。这里提一点，为什么http可以同时发送多个请求，但是这个多个请求也是由上限的，如果同时请求过多，连接数增大会导致浏览器负载压力很大，同时也不一定提高性能。所以一般要有个权衡。现在浏览器都有自己的设置，比如谷歌浏览器同一个域名下同时http请求数限制在6个。火狐浏览器也是6个，如下图
HTTP1.0存在的问题
1）明文传输，意味着没有压缩，导致传输效率低，在早期由于传输内容少，当时完全可以用的。对于现在web2.0时代随便打开一个网页可能都会加载十几个js，css文件还有很多图片。
2）传输方式是窜行的，就是说同时发送多个http请求，必须加载完第一个请求后才能加载第二个请求，然后以此类推，这种方式效率很低。
3）header头部很长，需要加载很多内容。
4）server端不能主动push（当然可以选择Websocket技术）。
4.HTTP/2.0（2015年）：
现在几乎所有的主流浏览器都支持http2.0协议。http2.0针对之前http版本一些缺陷做出了改进，尤其是性能上的优化，主要有下面的改进：
1）不再使用明文，而采用二进制的传输方式，头信息和数据体都是二进制，对明文进行了极大的压缩。
2）基于上面二进制方式，http2.0有一个新的概念，叫做帧（frame）。帧是http2.0中消息传递方式最小单位。这个是借鉴了bt下载的思想，将传输内容分成块进行传输，http2.0就是通过帧的形式打包进行传输请求头，请求体等信息。
3）HEAD 压缩。
4）服务器推送。
5）优先级请求。
6）多路复用。
7）HTTP2.0握手分2种方式，一种叫h2，一种叫h2c。h2要求必须使用TLS加密，在TLS握手期间会顺带完成HTTPS/2协议的协商，如果协商失败（比如客户端不支持或者服务端不支持），则会使用HTTPS/1继续后续通讯。h2c不使用TLS，而是多了一次基于HTTP协议的握手往返来完成向HTTP/2协议的升级一般不建议使用。
看下HTTP2.0 与HTTP1.0性能对比
上面这个网站显示两张图片，每张图片都是由几百张小图片组成，左边图片是利用HTTP1.0的技术去加载，右边是由HTTP2.0的技术加载。根据上面显示的时间可以看出HTTP2.0所需要的时间远远小于HTTP1.0的时间。这是因为HTTP1.0对于同一个域名同时最多只能建立6个连接，并且在请求完一个只会才能请求下一个。HTTP2.0通过帧的方式将传输数据打散然后在客户端重组。
5. HTTP/3.0协议与QUIC协议
QUIC协议：Quick UDP Internet Connections 的缩写，是一种传输层的协议，由谷歌2013年提出并发明的新传输协议。我们知道传输层主要的协议是TCP和UDP，TCP是面向连接的，在通信之前需要握手数据校验等，这样效率比较低。QUIC协议低出现就是解决减少基于TCP协议所带来的通信延迟还有其他的开销。
QUIC协议特点：
1. 不在面向连接，面向无连接。
2. 基于UDP协议做了改进，兼容了UDP的效率又兼具TCP的可靠性。
HTTP3.0最大特点就是将会从基于TCP的连接变成基于UDP的连接。
目前HTTP3还在发展中，未来HTTP3将来的变化未来可期。
相关文档：
HTTP RFC文档： https://www.w3.org/Protocols/rfc2616/rfc2616.html
HTTP2文档： http://http2.github.io/http2-spec/
https://hpbn.co/http2/#header-compression
SSL/TSL协议RFC文档： https://tools.ietf.org/html/rfc5246
HTTP协议特点
1. HTTP协议是应用层面向对象的协议。
2. HTTP是无连接的，HTTP客户端发起HTTP请求，发出请求后，客户端将断开与服务器的连接并等待响应。服务器处理请求并重新建立与客户端的连接以发回响应。
3. HTTP是无状态的，HTTP是无连接的，这是HTTP是无状态协议的直接结果。服务器和客户端仅在当前请求期间相互了解。之后他们就断开连接。所以客户端和浏览器都不能在跨网页的不同请求之间保留信息。
HTTP协议栈所在位置
HTTP协议与TCP协议关系
HTTP协议是构建在TCP/IP协议之上的，TCP协议对应于传输层，而HTTP协议对应于应用层，当浏览器需要从服务器获取网页数据的时候，会发出一次Http请求，Http会通过TCP建立起一个到服务器的连接通道，所以TCP决定数据如何在网络中传输，而HTTP主要解决如何包装数据并通过TCP传输数据到WEB服务器上。
那么HTTP协议一定是基于TCP协议的吗？
其实HTTP1.1 和 HTTP2 都是基于 TCP 传输协议的，而在新的HTTP/3中是基于 UDP 传输协议的。
HTTP三次握手
http在进行客户端和服务端建立通信链路的过程中需要创建tcp connection，因为http协议是工作在应用层，不承载连接任务都是基于tcp。http在在tcp基础上去进行请求和响应。而http在创建连接时候会有三次握手。
TCP三次握手时序图
HTTP协议请求与响应
一个 HTTP 请求有五个主要部分：
1. 动作（Verb） ：表明 HTTP 方法，比如 GET，POST，DELETE，PUT 等等。
2. URI ： 用来标识服务器上资源的统一资源标示符（URI）。
3. HTTP 版本 ：表明 HTTP 版本，比如 HTTP v1.1。
4. 请求头 ： 包含 HTTP 请求消息的元数据，它是键-值对形式的。比如，客户端（或者浏览器）类型，客户端支持的格式，消息体格式，缓存设置等等。
5. 请求体 ： 消息内容或者资源表示形式。
HTTP 响应有四个主要部分：
1. 状态/响应码 ： 表明请求资源的服务器状态。比如 404 意味着资源没有找到或者 200 意味着响应 OK。
2. HTTP 版本 ： 表明 HTTP 版本，比如 HTTP v1.1。
3. 响应头 ： 包含 HTTP 响应消息的元素数据，它是键-值对形式的。比如，内容长度，内容类型，响应日期，服务器类型等等。
4. 响应体 ： 响应消息内容或者资源表示形式。
HTTP状态码
HTTP状态码是用以表示网页服务器HTTP响应状态的3位数字代码。所有状态码的第一个数字代表了响应的五种状态之一。当用户试图通过HTTP或FTP协议访问一台运行主机上的内容时，Web服务器返回一个表示该请求的状态的数字代码。该状态代码记录在服务器日志中，同时也可能在 Web 浏览器或 FTP客户端显示。也就是我们打开页面发生错误时，浏览器显示的错误信息代码。状态代码可以指明具体请求是否已成功，还可以揭示请求失败的确切原因。
HTTP协议状态码表示的意思主要分为五类，大体是:
- 1××：保留
- 2××：表示请求成功地接收
- 3××：为完成请求客户需进一步细化请求
- 4××：客户错误
- 5××：服务器错误
下面是一些常见的HTTP状态码
| 状态码 |
解释 |
| 500 (内部服务器错误) |
对HTTP 500错误的定义已经充分证明了这是一个最常见的HTTP错误。 一般来说，HTTP 500 错误会在服务器的程序码出错时出现，或者web服务器发生内部错误时返回的信息。 例如，web服务器过载时将无法正确处理访问请求。 |
| 502 (无效网关) | 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。 |
| 503 (服务不可用) |
503错误也是服务器问题，表示服务当前不可用(Service unavaiable)，可能是因为当前服务器繁忙无法处理请求，比如连接数太高，cpu繁忙等。 |
| 404 (文件未找到) |
大多数人都知道这个错误。 当用户试图访问Web服务器（通常是一个网页）上某个实际不存在的资源时，就会发生404错误。404错误可能是由无效的链接引起，也可能是URL拼 写错误，还可能是因为虚拟主机将所请求页面移到其他地方（或删除所请求页面）。一些网站设置了自定义页面以防止坏链接所产生的不良影响。 |
| 403 (禁止访问) |
403错误类似于401错误，不同之处在于401错误是未经授权，而403错误是禁止访问。 任何登录对403错误都不起作用。尝试访问（被禁止的）网站目录时，就会发生403错误。 |
| 400 (错误请求) | Web服务器通过返回HTTP 400错误告诉访问者，访问者用来访问网站的程序出错，或访问请求途中遭到破坏。 |
| 401 (未经授权) | 访问者试图访问受限页面但未经授权时，网站返回HTTP 401错误。错误登录尝试是导致这一错误的主因。 |
| 301 (永久重定向) | 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。 |
| 302 (临时重定向) | 请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。 |
| 304 (Not Modified) |
请求资源没有改变，可以使用缓存的内容。在请求中附带了头部信息： 如果是 |
| 200 (请求成功) | 请求已成功，请求所希望的响应头或数据体将随此响应返回。 |
| 206 (部分内容) |
服务器已经成功处理了部分GET请求。类似于FlashGet或者迅雷这类的HTTP 下载工具，都是使用此类响应实现断点续传，或者将一个大文档分解为多个下载段同时下载。 |
HTTP协议方法
1. GET：提供资源的只读访问。
2. POST：用于更新现有资源或者创建一个新资源。
3. HEAD：和GET类似但是不返回响应body
4. OPTIONS：用于获取资源上支持的操作。
5. PUT：用于创建一个新资源。
6. PATCH
7. DELETE：用于移除一个资源。
8. TRACE
9. CONNECT
Get与POST请求的区别
GET与POST区别主要包括如下五个方面：
1. 从功能上讲，GET一般用来从服务器上获取资源，POST一般用来更新服务器上的资源；
2. 从REST服务角度上说，GET是幂等的，即读取同一个资源，总是得到相同的数据，而POST不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET不会改变服务器上的资源，而POST会对服务器资源进行改变；
3. 从请求参数形式上看，GET请求的数据会附在URL之后，即将请求数据放置在HTTP报文的 请求头 中，以?分割URL和传输数据，参数之间以&相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII)；而POST请求会把提交的数据则放置在是HTTP请求报文的 请求体 中。
4. 就安全性而言，POST的安全性要比GET的安全性高，因为GET请求提交的数据将明文出现在URL上，而且POST请求参数则被包装到请求体中，相对更安全。
5. 从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。
HTTP协议安全响应头
目的：保护用户的安全，也就是通常意义上的防止用户受到各种攻击，如XSS、CSRF。
1.Set-Cookie：由服务器端向客户端发送 cookie。
2. Access-Control-Allow-Origin：允许访问控制同源，实现跨域访问，它有多个CORS相关字段。
3. Authorization ：HTTP协议中的 Authorization 请求消息头含有服务器用于验证用户代理身份的凭证，通常会在服务器返回401 Unauthorized 状态码以及WWW-Authenticate 消息头之后在后续请求中发送此消息头。
4. X-XSS-Protection：用于开启浏览器的XSS过滤功能，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面，以防止XSS跨站脚本攻击。
5. Content-Security-Policy：中文名内容安全策略，主要思想是通过内容来源白名单机制，使浏览器仅渲染或执行来自这些来源的资源。允许站点管理者控制用户代理能够为某个页面获取哪些资源。
更多http安全信息可以访问 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials
HTTP协议中URL和URI区别
这两个看起来很相似，不了解的话容易迷糊。看看官方的解释：
URI (Universal Resource Identifier，统一资源标志符)：一个紧凑的字符串用来标示抽象或物理资源。一个URI可以被进一步分为定位符，名字或两者都是。就是代表一个网络资源的名称（name）。
URL(Universal Resource Locator，统一资源定位符)：是URI的子集，除了可以确定一个资源，还提供了一种定位该资源的访问机制，比如资源在网络中的位置，URL就是找到URI的地址。
URL格式: schema://host[:port]path search hash
schema: 协议头，表示访问资源和服务的协议。例如http,ftp,mailto,file等
host: 主机名，表示资源所在主机的完全限定域名。
port: 端口号，表示协议所使用的TCP端口号，http协议默认端口号80，https协议默认端口号443。
path: 路径，表示资源的目录/文件路径
两者区别
1. URL是URI的一种，不是所有的URI就是URL。
2. URI代表资源的名称，它标识一个互联网资源，URL代表资源的路径地址，并且可以根据这个地址去访问该资源。
URL和URI举例
| PATH | URL or URI | 说明 |
| ftp://ftp.is.co.za/rfc/rfc1808.txt | URL | 提供了FTP访问机制 |
| http://www.ietf.org/rfc/rfc2396.txt | URL | 提供了HTTP访问机制 |
| ldap://[2001:db8::7]/c=GB?objectClass?one | URL | 提供了LDAP访问机制 |
| tel:+1-816-555-1212 | URI | 只是一个描述，没有提供网路访问机制 |
| telnet://192.0.2.16:80/ | URL | 提供了TELNET访问机制 |
HTTP管道技术（Pipelining ）
一般浏览器会在收到上一个请求的响应之后，再发送下一个请求。而http管道技术就是可以将多个http请求同一批发送，这些http请求使用同一个 TCP 连接，而发送过程中客户端不需要等待服务器对前一个请求的响应。
http无管道和有管道示意图
HTTP Tunnel技术
在很多服务器上，防火墙会限制主机的出站流量，比如只允许80之类的端口。如果要使用其他端口，只能通过HTTP隧道(Tunnel)方式去实现。
HTTP缓存
HTTP换成分为两类：强制缓存，协商缓存。
HTTP缓存相关头信息：
1.强缓存：Pragma、Cache-Control、Expries。
2.协商缓存：Last-Modified/If-Modified-Since、Etag/If-None-Match。
HTTP代理
HTTP 代理（Web 代理）其实是一种存在于网络中间的实体，可以提供各种功能，位于客户端和服务端之间，扮演「中间人」的角色，在两端之间来回传递报文。。
Keep-Alive模式
多路复用
HTTP长连接和短链接
SPDY协议
SPDY（SPeeDY）是谷歌开发的基于TCP的会话层协议，SPDY的目的就是用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对原有HTTP协议的增强。谷歌先对HTTP协议层进行改进，在TSL协议之上增加一个会话层，在这个会话层中去实现SPDY协议，并不影响HTTP协议本来的数据格式，目的就是扩展和加强现有HTTP的功能。
HTTP协议应用-防盗链
HTTP状态与管理Cookie与Session
Cookie的产生就是为了解决 HTTP 协议无状态的问题。Cookie是能够让网站 Web 服务器把少量数据储存到客户端的硬盘或内存里，或是从客户端的硬盘里读取数据的一种技术。
原理：
服务端通过 Set-Cookie 这个响应头来向客户端中写入 Cookie 信息，而客户端读取 Set-Cookie 这个响应头中的信息存储起来，在下次请求的时候取出来，再通过 Cookie这个请求头，将 Cookie 的数据传输给服务端。
HTTP与HTTPS
由于HTTP协议本身是不够安全的，比如在我们登陆网站的时候，账号和密码经由Http协议传输到服务器上，这中间可能或有人可以截取信息，这样信息就会不安全，比如著名的中间人攻击。所以为了解决http在传输过程中不加密的问题，之后就增加了一个SSL协议，这个协议提供了数据安全和完整性，也就是负责网络连接安全。
RTT
RTT(Round-Trip Time)：往返时延。是指数据从网络一端传到另一端所需的时间。通常，时延由发送时延、传播时延、排队时延、处理时延四个部分组成。
1. 发送时延
发送时延是结点将数据分组发送到传输媒介所需要的时间，也就是从分组的第一个比特开始发送算起，到最后一个比特发送完毕所需要的时间。显然，发送时延与网络接口/信道的传输速率成反比，与数据分组的长度成正比。
2. 传播时延
传播时延是电磁波在信道中传播一定距离所需要花费的时间，传播时延和信道的传输速率无关， 而是取决于传输媒介的长度，以及某种物理形式的信号在传输媒介中的传播速度。如电磁波在自由空间的传播速度是光速，即3×105km/s。电磁波在网络传输媒体中的传播速度比在自由空间中的传播速度要略低一些，在铜线中的传播速度约为2.3×105km/s，在光纤中的传播速度约为2.0×105km/s 。
3. 排队时延
排队时延是分组在所经过的网络结点的缓存队列中排队所经历的时延，排队时延的长短主要取决于网络中当时的通信量，当网络的通信流量大时，排队时间就长，极端情况下，当网络发生拥塞导致分组丢失时，该结点的排队时延视为无穷大。此外，在有优先级算法的网络中，排队时延还取决于数据的优先级和结点的队列调度算法。
4. 处理时延
处理时延是分组在中间结点的存储转发过程中而进行的一些必要的处理所花费的时间，这些处理包括提取分组的首部，进行差错校验，为分组寻址和选路等。
参考来源：
https://mp.weixin.qq.com/s/xc8A2dKlZmPHUhFcAevPxw
