HTTPS的握手过程

http请求由三部分组成，分别是：请求行、消息报头、请求正文

HTTP（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。

1. 常用的HTTP方法有哪些？

   GET： 用于请求访问已经被URI（统一资源标识符）识别的资源，可以通过URL传参给服务器。

   POST：用于传输信息给服务器，主要功能与GET方法类似，但一般推荐使用POST方式。

   PUT： 传输文件，报文主体中包含文件内容，保存到对应URI位置。 HEAD： 获得报文首部，与GET方法类似，只是不返回报文主体，一般用于验证URI是否有效。

   DELETE：删除文件，与PUT方法相反，删除对应URI位置的文件。

   OPTIONS：查询相应URI支持的HTTP方法。

2. GET方法与POST方法的区别

   区别一： get重点在从服务器上获取资源，post重点在向服务器发送数据；

   区别二： get传输数据是通过URL请求，以field（字段）= value的形式，置于URL后，并用”?”连接，多个请求数据间用”&”连接，如http://127.0.0.1/Test/login.action?name=admin&password=admin，这个过程用户是可见的； post传输数据通过Http的post机制，将字段与对应值封存在请求实体中发送给服务器，这个过程对用户是不可见的；

   区别三： Get传输的数据量小，因为受URL长度限制，但效率较高； Post可以传输大量数据，所以上传文件时只能用Post方式；

   区别四： get是不安全的，因为URL是可见的，可能会泄露私密信息，如密码等； post较get安全性较高；

   区别五： get方式只能支持ASCII字符，向服务器传的中文字符可能会乱码。 post支持标准字符集，可以正确传递中文字符。

3. HTTP请求报文与响应报文格式

请求报文包含三部分： a、请求行：包含请求方法、URI、HTTP版本信息 b、请求首部字段 c、请求内容实体 响应报文包含三部分： a、状态行：包含HTTP版本、状态码、状态码的原因短语 b、响应首部字段 c、响应内容实体

1. 常见的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：请求需要认证
403：请求的对应资源禁止被访问
404：服务器无法找到对应资源
500：服务器内部错误
503：服务器正忙

1. HTTP1.1版本新特性

• 默认持久连接节省通信量，只要客户端服务端任意一端没有明确提出断开TCP连接，就一直保持连接，可以发送多次HTTP请求

• 管线化，客户端可以同时发出多个HTTP请求，而不用一个个等待响应

• 断点续传原理

1. 常见HTTP首部字段

    a、通用首部字段（请求报文与响应报文都会使用的首部字段）
    Date：创建报文时间
    Connection：连接的管理
    Cache-Control：缓存的控制
    Transfer-Encoding：报文主体的传输编码方式
   
    b、请求首部字段（请求报文会使用的首部字段）
    Host：请求资源所在服务器
    Accept：可处理的媒体类型
    Accept-Charset：可接收的字符集
    Accept-Encoding：可接受的内容编码
    Accept-Language：可接受的自然语言
   
    c、响应首部字段（响应报文会使用的首部字段）
    Accept-Ranges：可接受的字节范围
    Location：令客户端重新定向到的URI
    Server：HTTP服务器的安装信息
   
    d、实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
    Allow：资源可支持的HTTP方法
    Content-Type：实体主类的类型
    Content-Encoding：实体主体适用的编码方式
    Content-Language：实体主体的自然语言
    Content-Length：实体主体的的字节数
    Content-Range：实体主体的位置范围，一般用于发出部分请求时使用
   

2. HTTP的缺点与HTTPS

   a、通信使用明文不加密，内容可能被窃听

   b、不验证通信方身份，可能遭到伪装

   c、无法验证报文完整性，可能被篡改

HTTPS就是HTTP加上加密处理（一般是SSL安全通信线路）+认证+完整性保护

1. HTTP优化

利用负载均衡优化和加速HTTP应用 利用HTTP Cache来优化网站

1. 什么是URI

URI：统一资源标识符，在世界范围内唯一标识并定位信息资源。

URI有两种形式：URL和URN。

1. 什么是URL？

URL：统一资源定位符。URL描述了一台特定服务器上某资源的特定位置。 URL的第一部分被称为方案（scheme）。说明了访问资源所使用的协议类型。这里使用的时HTTP协议（http://）。 第二部分表示服务器的因特网地址：www.cnblogs.com。 其余部分指定了Web服务器上的某个资源：/jackson0714/p/algorithm_1.html。 几乎所有的URLI都是URL。

8.什么是URN？

URN:统一资源名，URN是作为特定内容的唯一名称使用的，与目前的资源所在地无关。

1. HTTP应用层协议。

它把联网的细节都交给了通用、可靠的因特网传输协议TCP\IP协议。

HTTP网络协议栈:

TCP协议：

　　a.传输控制协议

　　b.无差错的数据传输

　　c.按序传输（数据总是会按照发送的顺序到达）

　　d.未分段的数据流（可以在任意时刻以任意尺寸将数据发送出去

1. 输入URL到获取资源过称

在浏览器地址栏输入一个HTTP的URL地址，按下回车键之后，浏览器怎么通过HTTP显示位于远端服务器中的某个简单HTML资源?

（1）浏览器从URL中解析出服务器的主机名；

（2）浏览器将服务器的主机名转换成服务器的IP地址；

（3）浏览器将端口号（如果有的话），从URL中解析出来；

（4）浏览器建立一条与Web服务器的TCP连接；

（5）浏览器向服务器发送一条HTTP请求报文；

（6）服务器向浏览器回送一条HTTP响应报文；

（7）关闭连接，浏览器显示文档。

HTTP2.0

使用HTTP2.0测试便可看出HTTP2.0比之前的协议在性能上有很大的提升。下面总结了HTTP2.0协议的几个特性。

多路复用 (Multiplexing)

多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一，拿 Twitter 为例，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 算法。

服务端推送（Server Push）

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

HTTPS

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

HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的简单描述如下：

1.浏览器将自己支持的一套加密规则发送给网站。

2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。

3.获得网站证书之后浏览器要做以下工作：

a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。

b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。

c) 使用约定好的HASH计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。

4.网站接收浏览器发来的数据之后要做以下的操作：

a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。

b) 使用密码加密一段握手消息，发送给浏览器。

5.浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。

这里浏览器与网站互相发送加密的握手消息并验证，目的是为了保证双方都获得了一致的密码，并且可以正常的加密解密数据。其中非对称加密算法用于在握手过程中加密生成的密码，对称加密算法用于对真正传输的数据进行加密，而HASH算法用于验证数据的完整性。由于浏览器生成的密码是整个数据加密的关键，因此在传输的时候使用了非对称加密算法对其加密。非对称加密算法会生成公钥和私钥，公钥只能用于加密数据，因此可以随意传输，而网站的私钥用于对数据进行解密，所以网站都会非常小心的保管自己的私钥，防止泄漏。

TLS握手过程中如果有任何错误，都会使加密连接断开，从而阻止了隐私信息的传输。正是由于HTTPS非常的安全，攻击者无法从中找到下手的地方，于是更多的是采用了假证书的手法来欺骗客户端，从而获取明文的信息。默认HTTP的端口号为80，HTTPS的端口号为443。