HTTP相关

一、基础概念

1.URI和URL
URI(Uniform Resource Identifier) 是统一资源标识符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。
通俗来说，URL是URI的子集。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。URI的作用像身份证号一样，URL的作用更像家庭住址一样。
2.HTTP基础概念

（1）HTTP协议用于客户端和服务端之间的通信

（2）通过请求和响应的交换达成通信
请求报文：由请求方法，请求URI，协议版本，可选的请求首部字段和内容实体构成。

响应报文：基本上由协议版本，状态码，用以解释状态码的原因短语，可选的响应首部字段以及实体构成

（3）HTTP是不保存状态的协议
HTTP是一种不保存状态的协议，即无状态协议。HTTP协议自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个级别，协议对发送过的请求和响应都不做持久化处理。

如何解决实现保存状态的功能？
Cookie:
由于 http 协议是无状态协议，如果客户通过浏览器访问 web 应用时没有一个保存用户访问状态的机制，那么将不能持续跟踪应用的操作。比如当用户往购物车中添加了商品，web 应用必须在用户浏览别的商品的时候仍保存购物车的状态，以便用户继续往购物车中添加商品。

cookie 是浏览器的一种缓存机制，它可用于维持客户端与服务器端之间的会话。由于下面一题会讲到session，所以这里要强调cookie会将会话保存在客户端（session则是把会话保存在服务端）

这里以最常见的登陆案例讲解cookie的使用过程：

1. 首先用户在客户端浏览器向服务器发起登陆请求
2. 登陆成功后，服务端会把登陆的用户信息设置 cookie 中，返回给客户端浏览器
3. 客户端浏览器接收到 cookie 请求后，会把 cookie 保存到本地（可能是内存，也可能是磁盘，看具体使用情况而定）
4. 以后再次访问该 web 应用时，客户端浏览器就会把本地的 cookie 带上，这样服务端就能根据 cookie 获得用户信息了

Session:
session 是一种维持客户端与服务器端会话的机制。但是与 cookie 把会话信息保存在客户端本地不一样，session 把会话保留在浏览器端。

我们同样以登陆案例为例子讲解 session 的使用过程：

1. 首先用户在客户端浏览器发起登陆请求
2. 登陆成功后，服务端会把用户信息保存在服务端，并返回一个唯一的 session 标识给客户端浏览器。
3. 客户端浏览器会把这个唯一的session 标识保存在起来
4. 以后再次访问 web 应用时，客户端浏览器会把这个唯一的 session 标识带上，这样服务端就能根据这个唯一标识找到用户信息。

看到这里可能会引起疑问：把唯一的 session 标识返回给客户端浏览器，然后保存起来，以后访问时带上，这难道不是 cookie 吗？

没错，session 只是一种会话机制，在许多 web 应用中，session 机制就是通过 cookie 来实现的。也就是说它只是使用了 cookie 的功能，并不是使用 cookie 完成会话保存。与 cookie 在保存客户端保存会话的机制相反，session 通过 cookie 的功能把会话信息保存到了服务端。

进一步地说，session 是一种维持服务端与客户端之间会话的机制，它可以有不同的实现。以现在比较流行的小程序为例，阐述一个 session 的实现方案：

1. 首先用户登陆后，需要把用户登陆信息保存在服务端，这里我们可以采用 redis。比如说给用户生成一个 userToken，然后以
   userId 作为键，以 userToken 作为值保存到 redis 中，并在返回时把userToken 带回给小程序端。
2. 小程序端接收到 userToken 后把它缓存起来，以后每当访问后端服务时就把 userToken 带上。
3. 在后续的服务中服务端只要拿着小程序端带来的 userToken 和 redis 中的 userToken 进行比对，就能确定用户的登陆状态了。

Cookie和Session的区别：
1.概念上：cookie 是浏览器提供的一种缓存机制，它可以用于维持客户端与服务端之间的会话
session 指的是维持客户端与服务端会话的一种机制，它可以通过 cookie 实现，也可以通过别的手段实现。
ps:

session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了
cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）

2.存储上：cookie数据存放在客户端，session数据放在服务器上。
3.安全性：cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗考虑到安全应当使用session。所以将登陆信息等重要信息存放为SESSION。其他信息如果需要保留，可以放在COOKIE中
4.性能：session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用Cookie。

二、HTTP方法（常用）

GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。
POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。
PUT：传输文件，报文主体中包含文件内容，保存到对应URI位置。
HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。
DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。
OPTIONS：查询相应URI支持的HTTP方法。

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.就安全性而言，GET不如POST安全，因为POST用body传输数据，而GET用url传输，更加容易看到。但是从攻击的角度，无论是GET还是POST都不够安全，因为HTTP本身是明文协议。每个HTTP请求和返回的每个byte都会在网络上明文传播，不管是url，header还是body。这完全不是一个“是否容易在浏览器地址栏上看到“的问题。要保证安全就用HTTPS。

5.从请求的大小看，GET请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

三、HTTP状态码

1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受
3xx：重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现
5xx：服务器端错误–服务器未能实现合法的请求

200：请求被正常处理
204：请求被受理但没有资源可以返回
206：表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求，响应报文中通过Content-Range指定范围的资源。

301：永久性重定向 302：临时重定向(可以用来做网址劫持)
303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304：发送附带条件的请求时，条件不满足时返回，与重定向无关
307：临时重定向，与302类似，只是强制要求使用POST方法

400：请求报文语法有误，服务器无法识别
401：表示发送的请求需要有通过HTTP认证的认证信息。
403：对请求资源的访问被服务器拒绝了
404：服务器无法找到对应资源，url可能不正确

500：服务器内部错误，可能存在bug
503：表明服务器暂时处于超负荷或正在进行停机维护，现在无法处理请求。

四、HTTP版本

1.HTTP/0.9
HTTP协议的最初版本，功能简陋，仅支持 GET 方法，并且仅能请求访问 HTML 格式的资源

2 .HTTP/1.0

• 增加了请求方式 POST 和 HEAD
• 不再局限于0.9版本的HTML格式，根据Content-Type可以支持多种数据格式，即MIME多用途互联网邮件扩展，例如text/html、image/jpeg等
• 同时也开始支持 cache，就是当客户端在规定时间内访问统一网站，直接访问cache即可
• HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等
  但是1.0版本的工作方式是每次TCP连接只能发送一个请求，当服务器响应后就会关闭这次连接，下一个请求需要再次建立TCP连接，就是不支持keepalive

3.HTTP/1.0+

在20世纪90年代中叶，为满足飞快发展的万维网，很多流行的 Web 客户端和服务器飞快的向 HTTP 中添加各种特性，包括持久的 keep-alive 连接、虚拟主机支持，以及代理连接支持都被假如到 HTTP 中，并称为非官方的事实标准。这种非正式的 HTTP 扩展版本通常称为 HTTP/1.0+

4.HTTP/1.1

• http1.1是目前最为主流的http协议版本，从1997年发布至今，仍是主流的http协议版本。
• 引入了持久连接，或叫长连接（ persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。
• 引入了管道机制（ pipelining），即在同一个TCP连接里，客户端可以同时发送多个请求，进一步改进了HTTP协议的效率。
• 新增方法：PUT、 PATCH、 OPTIONS、 DELETE。
• http协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度。

5.HTTP/2.0（又名 HTTP-NG）

• http/2发布于2015年，目前应用还比较少。
• http/2是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为"帧"（frame）：头信息帧和数据帧。
• 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了队头堵塞的问题,此双向的实时通信称为多工（ Multiplexing）。
• HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送。 引入头信息压缩机制（ header compression）,头信息使用gzip或compress压缩后再发送。

HTTP1.0和HTTP1.1区别？

（1）HTTP1.0和HTTP1.1最主要的区别就是：HTTP1.1默认是持久化连接！在HTTP1.0默认是短连接，HTTP
1.0需要使用keep-alive参数来告知服务器端要建立一个长连接。

• 短链接简单来说就是每次与服务器交互，都需要新开⼀个连接！试想⼀下：请求⼀张图⽚，新开⼀个连接，请求⼀个CSS⽂件，新开⼀个连接，请求⼀个JS⽂件，新开⼀个连接。HTTP协议是基于TCP的，TCP每次都要经过三次握⼿，四次挥⼿，慢启动…这都需要去消耗我们⾮常多的资源的！
• 长链接：在HTTP1.1中默认就使⽤持久化连接来解决：建⽴⼀次连接，多次请求均由这个连接完成！(如果阻塞了，还是会开新的TCP连接的)
  （2）相对于持久化连接还有另外⽐较重要的改动：
  HTTP 1.1增加host字段
  HTTP 1.1中引⼊了Chunkedtransfer-coding ，范围请求，实现断点续传(实际上就是利⽤ HTTP消息头使⽤分块传输编码，将实体主体分块传输)
  HTTP 1.1管线化(pipelining)理论，客户端可以同时发出多个HTTP请求，⽽不⽤⼀个个等待响应之 后再请求 注意：这个pipelining仅仅是限于理论场景下，⼤部分桌⾯浏览器仍然会选择默认关闭HTTP pipelining！
  所以现在使⽤HTTP1.1协议的应⽤，都是有可能会开多个TCP连接的！

HTTP1.0和HTTP2.0区别？

（1） 多路复用

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

（3）服务器推送

当我们对支持HTTP2.0的webserver请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，免得客户端再次创建连接发送请求到服务器端获取。这种方式非常合适加载静态资源。服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。

服务端推送过来的资源，会统一放在一个网络与http缓存之间的一个地方，在这里可以理解为“本地”。当客户端把index.html解析完以后，会向本地请求这个资源。由于资源已经本地化，所以这个请求的速度非常快，这也是服务端推送性能优势的体现之一。

五、HTTPS

HTTP缺点：

• 通信使用明文不对数据进行加密（内容容易被窃听）
• 不验证通信方身份（容易伪装）
• 无法确定报文完整性（内容易被篡改）

因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。
为了解决HTTP协议的这一缺陷，需要使用另一种协议：安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL（安全套接层）协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密

与 SSL（安全套接层）组合使用的 HTTP 就是 HTTPS

HTTP和HTTPS对比
HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

HTTPS和HTTP的区别主要如下：

• https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
• http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
• http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

对称加密与非对称加密

主要的加密方法分为两种：一种是共享密钥加密（对称密钥加密），一种是公开密钥加密（非对称密钥加密）

（1）共享密钥加密(对称秘钥加密)

加密与解密使用同一个密钥，常见的对称加密算法：DES，AES，3DES等。
也就是说在加密的同时，也会把密钥发送给对方。在发送密钥过程中可能会造成密钥被窃取，那么如何解决这一问题呢？

（2）公开密钥（非对称密钥）
公开密钥使用一对非对称密钥。一把叫私有密钥，另一把叫公开密钥。私有密钥不让任何人知道，公有密钥随意发送。公钥加密的信息，只有私钥才能解密。常见的非对称加密算法：RSA，ECC等。

也就是说，发送密文方使用对方的公开密钥进行加密，对方接受到信息后，使用私有密钥进行解密。
对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。

非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

为了解决这一问题，https采用对称加密与非对称加密的混合加密方式。

SSL/TSL
SSL（Secure Sockets Layer），中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。

SSL 协议就是用来解决 HTTP 传输过程的不安全问题，到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。

很多相关的文章都把这两者并列称呼（SSL/TLS），因为这两者可以视作同一个东西的不同阶段。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

但是，这里有两个问题。

• HTTPS的工作原理
• 1.Client 使用https的URL访问 Server，要求与 Server 建立 SSL 连接
• 2.Server 把事先配置好的公钥证书返回给客户端。
• 3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。
• 4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
• 5.Server使用自己的私钥（privatekey）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
• 6.Server使用对称密钥加密“明文内容A”，发送给Client。
• 7.Client使用对称密钥解密响应的密文，得到“明文内容A”。
• 8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。
  

HTTPS的优点
尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

• 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
• HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
• HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
  谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

HTTPS的缺点
虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

• HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
• HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
• SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
• SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
• HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

六、Other

从输入网址到获得页面的过程

1. 浏览器查询DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
2. 浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
3. TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
4. 服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
5. 浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
6. 浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

XSS 攻击

XSS是一种经常出现在web应用中的计算机安全漏洞，与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

参考：https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247488741&idx=2&sn=32c62d632ec7e728b3e8b2c5cffe7263&chksm=ebd755e4dca0dcf256158f4215fa753285a8535a71d3ea9754932172f75705664e8c2f4e77d2&mpshare=1&scene=1&srcid=&sharer_sharetime=1591022821923&sharer_shareid=7b5238f8850a1b0a3b2ded6213a4410e&key=04f24b4b7c0e79503c1426f06f2c7831dd38d51f53c61d3257961245cf903e9889a9baa4a97ffe2b6bfa9436860b5582acb522691eb4d5c400563f680a204f2f7b2aaa30bffb2e63b13ded6ec9536fb3&ascene=1&uin=ODgwMjU1OTY%3D&devicetype=Windows+10+x64&version=6209007b&lang=zh_CN&exportkey=A1nRRj%2B0VTBGJFtNzFzLmGs%3D&pass_ticket=jZjJDnbY0mnAFjR%2Byld7%2BQmAeYqdnc5rB%2FIW9XI1lT0%3D