HTTP协议和HTTPS协议

各层协议

1.HTTP协议

• HTTP（超文本传输协议）是应用层协议，并且是无状态协议，协议本身并不会保存用户的任何信息，每次请求都是独立的。
• 独立的请求可以减小服务器的压力，支持更大的并发请求。

1. RTT

   • 请求往返时间。从请求一个发送开始到接收到接收端的确认信息所经历的的时间就是一个RTT。
   • 一个完整的请求需要2个RTT和文件传输的时间.

2. HTTP/1.0 

   • 缺点：非持续性连接（短连接） ，每次请求都需要2个RTT的开销（每次都三次握手）。
   • 服务器负担很重，但是浏览器可以同时多个并行的TCP连接，每个连接处理一个请求，这样可以缩短响应时间。

3. HTTP/1.1

   1. 持续性连接（长连接），发送请求之后一段时间里获得持续连接，之后的请求可以通过该链接持续发送，并且不局限于同一页面，只要是对同一服务器请求即可。
   2. 1.1默认流水线（管道）方式：在收到响应报文之前，可以持续发送请求报文，这样所有的请求只用一个RTT。
   3. 非流水线方式：只有收到前一个报文的响应报文才会发送下一个请求报文，这样每一个请求都要用一个RTT。 
   4.  POST不支持流水线，如刷新页面就会被提示重定向。GET 支持流水线方式。

2.HTTP报文结构

1. 请求报文

 

 

1. 1. 请求报文有3部分组成：

      1. 请求行： 请求方法  URL  版本号
      2. 首部行： 首部字段：value  （可以有若干项，信息最丰富）
      3. 实体主体： 存储资源信息（请求的信息），请求报文中一般不用，响应报文也有可能不用。
      • 请求行和首部行组成了报文首部（报文头）

   2. 请求方法有8种

      1. GET : 从服务器请求指定页的信息，并返回实体主体。
      2. POST : 向服务器提交数据，并进行处理。
      3. HEAD ： 类似于GET，但只获得响应报文头信息。
      4. PUT : 从客户端向服务器传送的数据取代指定的文档的内容。
      5. DELETE : 请求服务器删除指定的页面。
      6. CONNECT : HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
      7. OPTIONS : 允许客户端查看服务器的性能。
      8. TRACE ： 回显服务器收到的请求，主要用于测试或诊断。

   3. 自定义方法

      • 请求方法可以自定义  了解WebDAV

   4. 首部行

      • 首部行信息最为丰富，可以在HTTP协议通信过程中传递额外重要的信息。
      • 存储有关服务器和客户端的重要信息或者相关参数。

      1. 首部行有四种类型

         1. 通用首部：请求报文和响应报文两方都会使用的首部。
         2. 请求首部：请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
         3. 响应首部：响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。
         4. 实体首部：针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。
         • 请求头和响应头都可以自定义信息，这个特性在web中经常用到

      2. HTTP/1.1规范定义的首部

         • HTTP/1.1规范定义了很多首部信息如 Date,Host等。《图解HTTP》一书举例的非常详细。

      3. 不在HTTP/1.1规范定义的首部

         • Cookie、Set-Cookie 最常用的2个首部但他们却不是HTTP/1.1协议规定的，他们由别的协议规定。

2. 响应报文

1. 1. 响应报文也由三部分组成

      1. 状态行： 版本号 ，状态码，短语
      2. 首部行：
      3. 实体主体：存放表单数据

   2. 状态码由三位数组成

      • 第一个数字代表了响应的类别后两位无明显分类。

      1. 1XX : 通知信息，如请求收到了，或者正在处理。
      2. 2XX : 表示成功，请求正常处理完毕。
      3. 3XX ：重定向状态，需要附加操作以完成请求。
      4. 4XX ： 客户端错误，请求无法正常处理，如请求的资源不存在。
      5. 5XX : 服务器内部错误，处理请求时出错。

      • 常见的几个状态码和对应短语

        1. 200 请求成功
        2. 301 永久性重定向。该状态码表示请求的资源已被分配了新的URI，新的URL存放在响应头的Location中，浏览器会直接跳转到此URL。 求如果得到的响应是301那么，那么刷新浏览器再次响应就会发现不是301，因为新的URL已经被浏览器记录了下来，下一访问原URL会自动访问新URL。
        3. 302 临时性重定向。资源临时性改变了URL ,新URL同样放在响应头的Location中，浏览器会会直接跳转。如果的到的响应是302，那么访问原来URL一直是302，新URL不会被浏览器记住。
        4. 400 请求报文中存在语法错误。
        5. 403 该状态码表明对请求资源的访问被服务器拒绝了
        6. 404 找不到资源
        7. 503 服务器暂时处于超负载或正在进行停机维护

3.POST 和 GET

1. post 比 get 更加安全，get请求是明文传输。
2. post 比 get 传输的数据量更大，因为get受限于浏览器地址栏的字符数量限制，而post则不受限制。
3. post 可以使用更多数据类型，而get 只能使用 ASCII码。
4. post 比 get 慢，因为post先发送头部信息，再发送数据。相当于三次握手2个RTT和一个发送数据（实体主体）的RTT,一个三个RTT, 而get无实体主体，数据都在url中所以只需三次握手2个RTT, get/post = 2/3。

4.TCP报文格式

TCP 位于运输层，提供可靠的字节流服务。

1. 1. TCP报文首部

      • 如图，首部和TCP数据部分组成了TCP报文。
      • 序号：Seq用来表示报文段中数据每个字节的顺序。建立TCP连接后该序号随机产生一个初始标号，不一定从0开始。
      • 确认号：用小写ack表示，与标志字段的ACK区分，表示期望收到下一个报文段的第一个字节序号。

      • 6bit的标志字段，这6个控制字段来说明报文的性质

        1. URG : 
        2. ACK : 用来指示  确认号  是否有效,1有效0无效。
        3. PSH ：指示报文存在 紧急数据
        4. PST 
        5. SYN ：同步序列编号
        6. FIN :  他和 PST，SYN 共同用于连接建立和拆除

5.三次握手

1. 客户端发送一个SYN报文，设SYN = 1，并随机设置一个数字放置在序号Seq中。
2. 服务器发送允许连接的报文，SYN = 1, ACK = 1, 把确认号ack设为 收到的报文中的序号Seq + 1。服务器在随机设置一个序号Seq值。
3. 客户端收到服务器发送的确认报文 设置 SYN = 0,ACK = 1，在之后的传输中SYN = 0，ACK = 1。

• 为什么要三次握手，2次行不行？
  • 因为网络中存在延迟的重复分组（序号相同），重发的分组已经失效，如果没有第三次握手就会和这些失效的分组建立连接，造成服务器资源浪费。
• 客户端有7种状态，服务器有7种状态，他们会在不同状态之间循环。
• 第二次握手之后客户端进入ESTABLISHED（已建立连接）状态就可已发送数据了，所以第三次握手可以携带数据。

6.四次挥手

1. FIN = 1 ，终止报文，表示报文发送方数据发送完毕。注意：FIN 报文是不带数据的，但是它会消耗一个序号。
2. 确认报文 发送，服务器进入CLOSE-WAIT状态。此时客户端到服务器方向的连接断开了，而服务器到客户端的连接还没断开，如果服务器给客户端发送数据那么客户端还要接受该数据
3. 服务器再次发送终止报文FIN = 1。这是服务器请求断开连接。
4. 客户端收到终止报文后发送确认报文给服务器，并进入定时等待状态TIME-WAIT，时间到后关闭连接，服务器收到之后立刻关闭连接。

• 断开连接可以看成客户端和服务器分别都 “发送终止报文，并且作出回应”
• MSL : 报文段最长寿命，2MSL就是经过2倍最长寿命时间再关闭连接，一般有 30秒，1分钟或者2分钟。
• TIME-WAIT 状态保障了2点
  1. 保证最后一个报文到达服务器。如果客户端最后一个确认丢失，服务器会再次发送一个FIN= 1报文，这个时间段内客户端就会收到这个报文，再次发送确认报文。
  2.  2MSL 的时间足使以在本次连接中的所有报文都从网络中消失，这样就下一个新的连接中就不会出现旧连接中出现延迟的报文。
• 为什么握手需要三次而挥手需要四次？
  • 他两过程不一样，断开连接是需要双向断开的所以，断开时要四次。深层次原因就是FIN报文不能携带数据，第二次握手时可以把SYN和ACK是一起发送的，而断开时服务器FIN不能携带数据这样就不能和响应报文一起发送，因为响应报文有可能携带数据。

7.HTTP响应报文中的分块传送

• 请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。
• 分块传送也叫断点续传，主要在应答报文中，请求报文数据一般很小无需分块传送。
• 在HTTP1.1中需要在响应头设置 Content-length 表示整个消息数据的长度，这需要服务器提前计算出整个消息的长度。content-length是维持HTTP1.1 持久连接的一个关键点。
• 如果得到的content -length比实体中的数据小，那么就会截断实体中的数据，如果比实体中的数据长那么就会等待下一个响应数据直到全部数据传输完成。
• 这样存在一个问题如果消息过大那么计算消息长度花费时间多，或者动态展示内容时根本无法计算消息有多长。

1. HTTP1.1  分块传输编码

   • 分块传输编码可以将数据分成若干块，并一个或者多个发送，在客户端解码后即可还原数据。
   • 分块传输编码会将实体主体分成多个部分（块）。每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。
   • 采用 分块编码 需要在响应头设置 Transfer-Encoding :chunked，设置了就不需要设置content-length，如果有也会被忽略。

   • 分块传输好处

     1. 动态生成内容时用来维持长连接。因为持久性连接需要服务器设置发送消息的大小，但对于动态生成的对象无法知道大小，分块之后就可以知道每一块的大小，通常数据块的大小是一致的，但也不总是这种情况。
     2. 允许最后发送消息头字段，如头字段需要一些信息而这些信息必须要完整的数据给出。分块可以最后发送头字段，而不必缓冲全部数据后再发送。
     3. 可以一边压缩一边发送数据。

8.加密方式

1. 对称加密
   • 双方都使用相同的秘钥加密解密，也称共享加密，秘钥称为 对称秘钥。
   • 存在的问题：如何将共享秘钥安全的给对方？也许传输过程中会被别人截获，获得秘钥解密文件。
2. 非对称加密
   • 密文接收方产生2个不同的秘钥，公钥和私钥。不对外公开的就是私钥，放在网络中的就是公钥。他两只能一个加密一个解密。
   • 接收方把公钥发送给发送方，发送方使用公钥来加密，这样即使公钥和密文被截获，没有私钥也法破解密文。
   • 存在问题：接受公钥方如何确认接收到的就是正确的公钥，而不是被黑客替换了自己伪造的公钥？如果使用了伪造的公钥加密，那么黑客就可以用自己的私钥解密。
3. 数字签名：为防止公钥被替换
   • 数字证书机构 CA（Certificate Authority）使用自己的私钥对 公开的 公钥 加密，加密之后的就是数字证书它里面不仅仅有公钥还有数字证书机构服务器的相关信息。
   • 加密一方拿到数字证书后向数字证书机构查询是不是正确的公钥并解密，再使用解密后的公钥加密文件。

• 秘钥就是加密算法的参数。

9.HTTPS

1. 安全的HTTP协议，使用443端口
2. SSL套接字在应用层HTTP和运输层之间，SSL套接字接收到应用层数据加密后传递给TCP套接字。接收方一样可以从TCP套接字中读取后解密在提交个应用层。
3. HTTPS采用对称加密和非对称加密混合加密方式。
   1. 客户端向服务器端发起SSL连接请求
   2. 服务器把公钥发送给客户端，并且服务器端保存着唯一的私钥（存在隐患，可以使用数字证书解决）
   3. 客户端用公钥对双方通信的对称秘钥进行加密，并发送给服务器
   4. 服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密
   5. 进行数据传输，服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密，可以保证在数据收发过程中的安全，即是第三方获得数据包，也无法对其进行加密，解密和篡改。

4. HTTPS连接方式

   1. TCP连接建立，客户端发送请求报文开始SSL通信，报文中包含客户端支持的SSL版本，加密组件列表（几组可以使用的加密算法及密钥长度等）。
   2. 服务器可进行SSL通信时会发送响应报文，报文中包括选择的一个加密算法和秘钥长度。
   3. 之后服务器发送包含公开密钥证书的报文你给客户端。（服务器要已经在CA做了认证）
   4. 最后服务器发送报文通知客户端第一次SSL握手结束。
   5. SSL第一次握手结束后，客户端会用服务器的公开密钥加密 共享秘钥 并传输给服务器.
   6. 接着客户端会继承发送报文提示服务器，在此报文以后的通信将使用之前发送过去的  共享秘钥  进行加密处理。
   7. 最后客户端发送结束报文。　（第二次SSL握手结束）　
   8. 服务器同样发送报文提示客户端，在此报文以后的通信将使用客户端之前发送过来的  共享秘钥  进行加密处理。
   9. 服务器发送结束报文。　（第三次SSL握手结束）　
   10. 服务器和客户端的结束报文交换完后，SSL连接建立完成，开始HTTP请求
   • 对于HTTPS应用层发来的数据会加一个MAC的报文摘要。MAC能够查知报文是否遭到篡改，从而保护报文的完整性；

   • 总结HTTPS的三次握手

     1.  建立TCP连接，通过非对称加密方式将公钥交给客户端。
     2. 客户端使用公钥加密共享秘钥并发送个给服务器。
     3. 服务器对使用共享秘钥加密作出回应。

5.  HTTP与HTTPS的区别 

   1. HTTPS协议需要到ca申请证书，一般免费证书很少，需要交费。     

   2. HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的ssl加密传输协议。     

   3. HTTP和HTTPS使用的是完全不同的连接方式用的端口也不一样,前者是80,后者是443。   

   4. HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议， 要比http协议安全。

10.SSL

• SSL协议有三个特性
  1. 私密性：第一次握手之后指定了秘钥，之后通信都会使用这个秘钥加密解密。
  2. 确认性：服务器和客户都会被认证，客户的认证是可选的。
  3. 可靠性：SSL协议会使用MAC对传送的数据进行完整性检查。
• TLS 运输层安全协议
  • TSL协议是运输层的协议，SSL是安全套接字层他两有所区别。