HTTP与HTTPS

HTTP的全称叫超文本传输协议，其实我个人在工作中用到的HTTP都比较简单，所以可能对HTTP理解并不是很深入，下面只能讲一些最基本的东西。

一 基本概念

1 URI与URL

• URI: 统一资源标志符 , 在某一规则下能把一个资源独一无二地标识出来。
• URL: 通过唯一位置标识资源。URL是URI的子集。

二 状态码

HTTP的状态码非常多，光在RFC2616文档中定义的就有40种，加上RFC4918,5842,6585等，数量超过60种。但其实也没必要记住那么多，只要遵守如下的规范即可：

image.png

下面介绍一下常见的几个：

• 200：成功
• 301：永久重定向，返回301状态码进行跳转被Google认为是将网站地址由 HTTP 迁移到 HTTPS的最佳方法。
  实例：

客户端发出请求:

GET /blog HTTP/1.1
Host: www.example.com
服务器回应，不带Cache-Control头部:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
服务器回应，带Cache-Control头部:

HTTP/1.1 301 Moved Permanently
Location: http://www.example.org/index.asp
Cache-control: private; max-age=600

• 302：暂时重定向，尽量使用301跳转，因为在使用302时，跳转之后的页面可能url乱七八糟比较长，而原始的比较简洁，搜素引擎可能就将结果优化为不定向，那么就有可能发生url劫持。
• 303：和302功能一样，但是明确了重定向后要用GET方式请求URI.
• 404：我们最熟悉的404，表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。

GET和POST区别

提起GET和POST，本质的区别就是GET把参数包含在URL中，POST通过request body传递参数。由此又会衍生出一些其他区别：
从https://www.w3school.com.cn/tags/html_ref_httpmethods.asp 截了张图出来：

image.png

• 有些浏览器会对GET请求的长度做限制，但是这并不是http标准中的内容。
• 还有一点区别是：GET请求只会发送一次，POST会发送两次，第一次发送header后，服务端返回100：continue，然后客户端再继续发送data。

HTTP keep-alive和tcp keep-alive特性的区别

http的keepalive是在请求头中的一个特性，有了这个头部信息，http传输完不会立即断开tcp连接，同时操作系统会维持一个timeout，有些系统默认为5s，超过timeout后关闭tcp连接。而tcp的keepalive为一种保活特性，例如服务端过了一阵没有收到包，客户端发送一个心跳包告诉我还活着。
http如何判断已经发送完成？静态资源：content-length

HTTPS

先盖棺定论一下：HTTPS = HTTP+ 加密 + 认证 + 完整性保护。 --图解HTTP协议
首先要知道HTTPS不是一个什么新的网络协议，它只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。如果你用wireshark去抓HTTPS的包，它会认为你是个智障。

image.png
从上图可以看到，所谓的https就是在TCP和HTTP，也就是传输层和应用层之间多加了一个步骤。事实上现在用ssl的浏览器已经很少了，基本上都是在用tls.下面是一个加密示意图，
image.png

下面是抓包看到的：

image.png

步骤
首先要介绍对称加密和非对称加密的概念，对称加密就是加解密用同一个秘钥，非对称解密是发送端和请求端有分别有自己的公钥和私钥，公钥互通用于加密，发送加密后的报文后，可以用私钥解密。
如果仅仅采用这种对称加密或者非对称加密的方式，那么如果报文被黑客截取，同时返回黑客自己的公钥，那么客户端就是傻白甜，什么都不知道，在此基础上，就有了ssl或tls，这是一种权威的认证，一般含有认证机构，认证有效期，公钥等信息，浏览器会去检查证书的有效性，所以

HTTPS劣势

image.png

总结一下https服务，它要增加一部分通信损耗，然后服务器和客户端双方做加解密处理会多消耗一部分硬件资源，开销是比较大的，而且用这种权威的第三方认证机构（CA机构）的证书每年也要付一部分费用，所以说如果信息不是很敏感的话HTTP就够了。

第一步: 客户端生成的随机数（Client random）R1，以及客户端支持的加密方法。

第二步，服务端确认加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）R2。

第三步，然后生成一个新的随机数（Premaster secret）R3，并使用数字证书中的公钥，加密这个随机数。

第四步，服务端用自己的私钥，获取客户端发来的随机数R3。

第五步，客户端和服务端用约定的加密方法，并使用R1,R2,R3，生成"对话密钥"（session key），用来加密接下来的整个对话过程。

注意： 服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。

image.png