HTTP/1.1与HTTPS

关于HTTPS部分转载于 https://blog.youkuaiyun.com/xiaoming100001/article/details/81109617

目录

HTTP 1.1协议包

Get请求协议包

Response响应协议包

HTTP 1.1协议包

Get请求协议包

报文头：
GET /scrape.php?... HTTP/1.1\r\n
GET 表示请求方式
​
请求协议头：
Host:resource.xidian.edu.cn\r\n
User-Agent:uTorrent/2210(255302)\r\n
Accept-Encoding:gzip\r\n
Connection:Close\r\n
\r\n
Host：发送请求时，Host是必需的，用于指定被请求资源的主机和端口号。
    能够从HTTP URL中提取出来。HTTP/1.1 必须包含主机头域，否则会报404
User-Agent：告知HTTP服务器，客户端使用的操作系统和浏览器内核版本。
Accept-Encoding：浏览器自己可接受的编码方式，通常会说明是否支持压缩并指定压缩方法。通过压缩可以节省5~10倍的下载时间。若没有设置该域，则假设对各种编码都支持。
Clooention：一般只有Keep-alive与close两个值。
    区别：之前版本HTTP协议是对每个请求都会创建一个连接，在这个连接上发送请求，接受响应，之后关闭。虽然很容易理解但效率很低。
    Keep-alive使客户端到服务器端的连接持续有效，直到一端明确提出要断开连接时才终止。出现后继请求时，避免了建立连接和重新建立连接。大部分web服务器，包括IIS、Apache等都支持Keep-alive。
    但Keep-alive也有缺点，虽然为客户保留打开的连接有一定的好处，但对于大型网站来说，本来释放的资源此时仍没有释放，对资源利用有极大的影响。
​
​
一般包头还会包括：
Accept：浏览器端可接受的MIME类型。如text/html表示浏览器可接受服务器会发的类型为text/html，就是常用的html文档，若无法返回该类型，则会返回一个406错误。
    通配符*表示任意类型，Accept：*/*表示任何类型。
Cache-Control：指定请求和响应遵循的缓存机制。
    缓存指令是单向（请求不会影响响应）且独立的（不会修改另一个消息处理过程的缓存设置）
    请求时指令包括：no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached
    响应时指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage等
Accept-Language：声明浏览器接受的语言，中文，中文有多种字符集big5、gb2312、gbk等
Accept-Charset：声明浏览器可接受的字符集
​

HTTP/1.1协议中共有9种方法来表明Request-URI指定的资源的不同操作方式（方法名称是大小写区分的）

1、OPTIONS：返回服务器针对特定资源所支持的 HTTP 请求方法
2、HEAD：向服务器索要与GET请求相一致的响应，但不返回响应体。常用于测试超链接的有效性
3、GET：向特定资源发出请求，默认为GET
4、POST：向特定资源提交数据并处理请求，用于提交表单或上传文件，数据包含在请求体中。
5、PUT：向指定资源位置上传最新内容
6、DELETE：请求服务器删除Request-URI所表示的资源
7、TRACE：回显服务器收到的请求，一般用于测试或诊断
8、CONNECT：HTTP/1.1中预留给能够将连接改为管道方式的代理服务器
9、PATCH：将局部修改应用于某一资源
​
GET和POST的区别
     1. GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如register.html?name=test1&id=123456. POST方法是把提交的数据放在HTTP包的Body中.
    2. GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据没有限制.
    3. GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值。
    4. GET方式提交数据，会带来安全问题，比如一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码

Response响应协议包

 

报文头：
HTTP/1.1 301 Moved Permanently\r\n
    第一个字段表明HTTP协议版本，第二个字段为状态码，相当于请求结果，被HTTP官方定义，最后一个字段为状态码的说明字符串
    状态码由三位数组组成，第一个数字定义了响应的类别，
    1xx：指示信息，表示请求已接受，继续处理
    2xx：成功，请求已被成功接收、理解、接受
    3xx：重定向，要完成请求需进一步的操作
    4xx：客户端错误，请求语法有误或请求无法实现
    5xx：服务端错误，服务器未能实现合法请求
    常见状态码：
    200 OK          // 客户端请求成功
    400 Bad Request  // 客户端语法错误
    401 unauthorized // 未经请求授权
    403 Forbidden    // 服务器收到请求，但拒绝提供服务
    404 Not Found    // 请求资源不存在
    500 internal Server Error // 服务器发生错误
    503 Server Unavailable // 服务器当前不能处理客户端请求，一段时间后恢复正常
响应协议头：
Date：消息发送时间
Server：web服务器用来处理请求的软件信息
Content-Encoding：服务器压缩方式
Content-Length：响应对象的长度
Content-Type：响应对象的类型

HTTPS

HTTP：超文本传输协议，是一个基于请求与响应，无状态的应用层协议，常基于TCP/IP协议传输数据，互联网上应用最广泛的一种网络协议，所有的 www文件都必须遵循这个标准。设计HTTP的初衷是为了提供一种发布和接受HTML页面的方法

HTTPS：HTTP+SSL，是一种通过计算机网络进行安全通信的传输协议，利用 SSL（TSL的前身）或 TSL（传输层加密协议）建立全信道，加密数据包。主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。

特点

• 内容加密：通过混合加密技术，中间者无法直接查看明文内容，而HTTP是可以直接看到内容的

• 身份认证：通过 CA证书认证服务器的合法性

• 保护数据完整性：防止传输的内容被中间人冒充或篡改

混合加密：采用对称加密和非对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密，然后使用非对称加密的公钥再对密钥进行加密，所以网络上传输的数据是被密钥加密的密文和用公钥加密后的秘密密钥，因此即使被黑客截取，由于没有私钥，无法获取到加密明文的密钥，便无法获取的明文数据。

数字摘要：通过单向 hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文。

数字签名技术：数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术。

• 收方能够证实发送方的真实身份；

• 发送方事后不能否认所发送过的报文；

• 收方或非法者不能伪造、篡改报文。

对称加密：此时必须双方都知道加密的密钥，并且加密解密用的是同一个密钥。一般实际中有多个对称加密算法。

A (密钥K加密) ---------------------------------->B(密钥K解密) hello slkgdhglk*&&# hello

对称加密要首先对将使用的密钥告知对方，此时只能使用明文，这样的话中间人也能够捕获到该密钥，还是不安全的。此时需要使用非对称加密技术。

非对称加密：此处有个公钥和私钥的区别，一般密码学中，公钥和私钥是成对出现的

• 公钥是对所有人开放的，私钥是保密的，只有一个人有，存在于服务器端

• 公钥加密后的密文，只有私钥可以解密

• 私钥加密后的密文，只要是公钥都可以解密

所以从客户端向服务器端请求数据时，先用服务器端的公钥加密内容，然后发送至服务器，服务器用自己的私钥解密，得到发送内容。 一般来说第一次客户端向服务器端发送的是一个自己生成的 密钥，服务器接收之后就能够使用该 密钥 进行双方通信。此处使用的是对称密钥。

现在又出现了一个问题，客户端如何才能安全地获取到服务器端的公钥呢？怎么保证服务器给客户端下发的是真正的公钥，而不是中间人伪造的公钥呢？

• 此时需要通过 CA证书来进行身份认证。证书包括 加密后的服务器密钥、权威机构的信息、服务器域名、通过CA私钥签名后的证书内容（经过先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名）、签名计算方法以及证书对应的域名。

• 当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要，然后根据证书上描述的计算证书的方法计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。

• 那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢？（伪装服务端一样的配置）显然这个是不行的，因为当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证明你是服务端域名的拥有者，而第三方攻击者是无法提供这些信息所以他就是无法骗CA他拥有属于服务端的域名