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是安全套接字层他两有所区别。