网络篇（一） HTTP&HTTP2.0&HTTPS
目录
HTTP
HTTP 简介
HTTP消息结构
请求报文
响应报文
头部信息
头部字段整理
请求方法
状态码
form表单中enctype数据类型的使用（待完善）
HTTP 2.0
二进制传输
多路复用
Header 压缩
服务端 Push
多版本HTTP比较
HTTPS
密码学基础
对称加密
非对称加密
HTTPS通信过程
参考资料：《计算机网络 自顶向下方法第6版》
HTTP
HTTP 简介
HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。。
HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。
HTTP 工作原理
HTTP协议工作于客户端-服务端架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
Web服务器有：Apache服务器，IIS服务器（Internet Information Services）等。
Web服务器根据接收到的请求后，向客户端发送响应信息。
HTTP默认端口号为80，但是你也可以改为8080或者其他端口。
HTTP特点：
- HTTP是无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
- HTTP是媒体独立的：这意味着，只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。客户端以及服务器指定使用适合的MIME-type内容类型。
- HTTP是无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
- 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。
以下图表展示了HTTP协议通信流程：
HTTP消息结构
请求报文
客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、首部行（header line）（请求头部啥的也行）、空行和实体主体（entity body）四个部分组成，下图给出了请求报文的一般格式。（配图来源《计算机网络自顶向下方法 第6版》）
- 请求行
- 请求类型
- 要访问的资源
- HTTP协议版本号
- 请求头（首部行）
- 用来说明服务器要使用的附加信息（一些键值对）
- 例如：User-Agent、 Accept、Content-Type、Connection
- 空行
- 分割请求头与请求体
- 请求体（实体主体）
- 可以添加任意的其他数据
响应报文
HTTP响应也由四个部分组成，分别是：状态行（status line）、首部行（header line 也有叫消息报头）、空行和实体主体（entity body 也有叫响应正文）。
可以对比Wireshark捕获的来看一下
- 状态行
- HTTP协议版本号
- 状态码
- 状态消息
- 消息报头
- 说明客户端要使用的一些附加信息
- 如：Content-Type、charset、响应的时间
- 响应正文
- 返回给客户端的文本信息
头部信息（首部行的分类）
HTTP的头域包括通用头、请求头、响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。
通用头域：请求和响应消息都支持的头域，可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能，如Date头部。
请求头部头域是请求报文特有的，它们为服务器提供了一些额外信息，比如客户端希望接收什么类型的数据，如Accept头部。
响应头域用于服务器为客户端提供信息，比如，客服端在与哪种类型的服务器进行交互，如Server头部。
实体头部：请求消息和响应消息都可包含实体信息，比如，可以用实体头部来说明实体主体部分的数据类型，如Content-Type头部。
常见头部
- Accept
- 在请求中使用Accept可申明想要的数据格式
- Accept-Encoding
- 告诉服务端使用什么的方式来进行压缩
- 例如：gzip、deflate、br
- Accept-Language
- 描述语言信息
- User-Agent
- 用来描述客户端浏览器相关信息
- 可以用来区分PC端页面和移动端页面响应头
- Content-Type
- 对应Accept，从请求中的Accept支持的数据格式中选一种来返回
- Content-Encoding
- 对应 Accept-Encoding，指服务端到底使用的是那种压缩方式
- Content-Language
- 对应Accept-Language
头部字段整理
| 通用字段 |
作用 |
| Cache-Control |
控制缓存的行为 |
| Connection |
浏览器想要优先使用的连接类型，比如 keep-alive https://blog.csdn.net/xiaoduanayu/article/details/78386508 |
| Date |
创建报文时间 |
| Pragma |
报文指令 |
| Via |
代理服务器相关信息 |
| Transfer-Encoding |
传输编码方式 |
| Upgrade |
要求客户端升级协议 |
| Warning |
在内容中可能存在错误 |
| 请求字段 |
作用 |
| Accept |
客户端希望接收的数据类型 |
| Accept-Charset |
能正确接收/希望接收的字符集 |
| Accept-Encoding |
能正确接收的编码格式列表（压缩即编码的一种） |
| Accept-Language |
能正确接收的语言列表 |
| Expect |
期待服务端的指定行为 |
| From |
请求方邮箱地址 |
| Host |
服务器的域名 |
| If-Match |
两端资源标记比较 |
| If-Modified-Since |
本地资源未修改返回 304（比较时间） |
| If-None-Match |
本地资源未修改返回 304（比较标记） |
| User-Agent |
客户端信息 |
| Max-Forwards |
限制可被代理及网关转发的次数 |
| Proxy-Authorization |
向代理服务器发送验证信息 |
| Range |
请求某个内容的一部分 |
| Referer |
表示浏览器所访问的前一个页面 |
| TE |
传输编码方式 |
| 响应字段 |
作用 |
| Accept-Ranges |
是否支持某些种类的范围 |
| Age |
资源在代理缓存中存在的时间 |
| ETag |
资源标识 |
| Location |
客户端重定向到某个 URL |
| Proxy-Authenticate |
向代理服务器发送验证信息 |
| Server |
服务器名字 |
| WWW-Authenticate |
获取资源需要的验证信息 |
| 实体字段 |
作用 |
| Allow |
资源的正确请求方式 |
| Content-Encoding |
内容的编码格式 |
| Content-Language |
内容使用的语言 |
| Content-Length |
request body 长度 |
| Content-Location |
返回数据的备用地址 |
| Content-MD5 |
Base64加密格式的内容 MD5检验值 |
| Content-Range |
内容的位置范围 |
| Content-Type |
发送端（客户端 | 服务器）发送的实体数据的类型 |
| Expires |
内容的过期时间 |
| Last_modified |
内容的最后修改时间 |
请求方法
HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
HEAD方法：当服务器收到使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。
PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径（目录），PUT方法也被那些需要向Web服务器上传对象的应用程序使用。
DELETE方法允许用户或应用程序删除Web服务器上的对象。
Post 和 Get 的区别
GET在浏览器回退时是无害的，而POST会再次提交
- Get请求能缓存，Post不能
- Post相对Get相对安全一些，因为Get请求都包含在URL中，而且会被浏览器保存记录，Post不会。但是再抓包的情况下都是一样的。
- Post 可以通过 request body来传输比 Get 更多的数据
- URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的
- Post 支持更多的编码类型且不对数据类型限制
- POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)
这里引入副作用和幂等的概念。
副作用指对服务器上的资源做改变，搜索是无副作用的，注册是副作用的。
幂等指发送 M 和 N 次请求（两者不相同且都大于 1），服务器上资源的状态一致，比如注册 10 个和 11 个帐号是不幂等的，对文章进行更改 10 次和 11 次是幂等的。
在规范的应用场景上说，Get 多用于无副作用，幂等的场景，例如搜索关键字。Post 多用于副作用，不幂等的场景，例如注册。
状态码
| 1** |
信息，服务器收到请求，需要请求者继续执行操作 |
| 2** |
成功，操作被成功接收并处理 |
| 3** |
重定向，需要进一步的操作以完成请求 |
| 4** |
客户端错误，请求包含语法错误或无法完成请求 |
| 5** |
服务器错误，服务器在处理请求的过程中发生了错误 |
常用：
| 状态码 |
英文名称 |
中文描述 |
| 100 |
Continue |
继续。客户端应继续其请求 |
| 101 |
Switching Protocols |
切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 |
OK |
请求成功，信息在返回的响应报文中。 |
| 201 |
Created |
已创建。成功请求并创建了新的资源 |
| 202 |
Accepted |
已接受。已经接受请求，但未处理完成 |
| 203 |
Non-Authoritative Information |
非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 |
No Content |
无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 |
Reset Content |
重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 |
Partial Content |
部分内容。服务器成功处理了部分GET请求 |
| 300 |
Multiple Choices |
多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 |
Moved Permanently |
永久移动。请求的对象已经被永久转移了，新的URL定义在响应报文的Location（header line）中。客户端将自动获取新的URL |
| 302 |
Found |
临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI。临时重定向？ |
| 303 |
See Other |
查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 |
Not Modified |
未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源（网页内容）。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 |
Use Proxy |
使用代理。所请求的资源必须通过代理访问 |
| 306 |
Unused |
已经被废弃的HTTP状态码 |
| 307 |
Temporary Redirect |
临时重定向。与302类似。使用GET请求重定向 |
| 400 |
Bad Request |
一个通用差错代码，表示该请求不能被服务器理解 |
| 401 |
Unauthorized |
请求要求用户的身份认证 |
| 402 |
Payment Required |
保留，将来使用 |
| 403 |
Forbidden |
服务器理解请求客户端的请求，但是拒绝执行此请求；权限？ |
| 404 |
Not Found |
服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 |
Method Not Allowed |
客户端请求中的方法被禁止 |
| 406 |
Not Acceptable |
服务器无法根据客户端请求的内容特性完成请求 |
| 407 |
Proxy Authentication Required |
请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 |
Request Time-out |
服务器等待客户端发送的请求时间过长，超时 |
| 409 |
Conflict |
服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突 |
| 410 |
Gone |
客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 |
Length Required |
服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 |
Precondition Failed |
客户端请求信息的先决条件错误 |
| 413 |
Request Entity Too Large |
由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 |
Request-URI Too Large |
请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 |
Unsupported Media Type |
服务器无法处理请求附带的媒体格式 |
| 416 |
Requested range not satisfiable |
客户端请求的范围无效 |
| 417 |
Expectation Failed |
服务器无法满足Expect的请求头信息 |
| 500 |
Internal Server Error |
服务器内部错误，无法完成请求 |
| 501 |
Not Implemented |
服务器不支持请求的功能，无法完成请求 |
| 502 |
Bad Gateway |
作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 |
Service Unavailable |
由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 |
Gateway Time-out |
充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 |
HTTP Version not supported |
服务器不支持请求的HTTP协议的版本，无法完成处理 |
form表单中enctype数据类型的使用（待完善）
- application/x-www-form-urlencoded
- key=value&key=value 格式
- multipart/form-data
- 用于提交文件
- multipart表示请求是由多个部分组成（因为上传文件的时候文件不能以字符串形式提交，需要单独分出来）
- boundary 用来分隔不同部分
- text/plain
HTTP 2.0
https://blog.csdn.net/zqjflash/article/details/50179235
HTTP 2.0 相比于 HTTP 1.X，可以说是大幅度提高了 web 的性能。
在 HTTP 1.X 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量，当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。关于同源和跨域的问题恐怕得另作文章了，可以先看下阮一峰老师的
。http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
二进制传输
HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。
多路复用
在 HTTP 2.0 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。
帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。
多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。
Header 压缩
在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。
在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。
服务端 Push
在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。
可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。
多版本HTTP比较
参考 https://www.cnblogs.com/heluan/p/8620312.html
- HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；
- HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的队头阻塞；
- HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；
HTTPS
http默认采用80作为通讯端口，对于传输采用不加密的方式，https默认采用443，对于传输的数据进行加密传输。
密码学基础
明文： 明文指的是未被加密过的原始数据。
密文：明文被某种加密算法加密之后，会变成密文，从而确保原始数据的安全。密文也可以被解密，得到原始的明文。
密钥：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥，分别应用在对称加密和非对称加密上。
对称加密
对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据。对称加密的特点是算法公开、加密和解密速度快，适合于对大数据量进行加密，常见的对称加密算法有DES、3DES、TDEA、Blowfish、RC5和IDEA。
其加密过程如下：明文 + 加密算法 + 私钥 => 密文
解密过程如下：密文 + 解密算法 + 私钥 => 明文
对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。
其加密过程中的私钥与解密过程中用到的私钥是同一个密钥，这也是称加密之所以称之为“对称”的原因。由于对称加密的算法是公开的，所以一旦私钥被泄露，那么密文就很容易被破解，所以对称加密的缺点是密钥安全管理困难。
非对称加密
非对称加密也叫做公钥加密。非对称加密与对称加密相比，其安全性更好。对称加密的通信双方使用相同的密钥，如果一方的密钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对密钥，即公钥和私钥，且二者成对出现。私钥被自己保存，不能对外泄露。公钥指的是公共的密钥，任何人都可以获得该密钥。用公钥或私钥中的任何一个进行加密，用另一个进行解密。
被公钥加密过的密文只能被私钥解密，过程如下：
明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文
被私钥加密过的密文只能被公钥解密，过程如下：
明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文
由于加密和解密使用了两个不同的密钥，这就是非对称加密“非对称”的原因。 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。 在非对称加密中使用的主要算法有：RSA、Elgamal、Rabin、D-H、ECC（椭圆曲线加密算法）等。
HTTPS通信过程
HTTPS协议 = HTTP协议 + SSL/TLS协议，在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。
SSL的全称是Secure Sockets Layer，即安全套接层协议，是为网络通信提供安全及数据完整性的一种安全协议。SSL协议在1994年被Netscape发明，后来各个浏览器均支持SSL，其最新的版本是3.0。
TLS的全称是Transport Layer Security，即安全传输层协议，最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。虽然TLS与SSL3.0在加密算法上不同，但是在我们理解HTTPS的过程中，我们可以把SSL和TLS看做是同一个协议。
HTTPS为了兼顾安全与效率，同时使用了对称加密和非对称加密。数据是被对称加密传输的，对称加密过程需要客户端的一个密钥，为了确保能把该密钥安全传输到服务器端，采用非对称加密对该密钥进行加密传输，总的来说，对数据进行对称加密，对称加密所要使用的密钥通过非对称加密传输。
HTTPS在传输的过程中会涉及到三个密钥：
- 服务器端的公钥和私钥，用来进行非对称加密
- 客户端生成的随机密钥，用来进行对称加密
一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。
- 客户端向服务器发起HTTPS请求，连接到服务器的443端口
- 服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
- 服务器将自己的公钥发送给客户端。
- 客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
- 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
- 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
- 然后服务器将加密后的密文发送给客户端。
- 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
SSL协议的脆弱性分析
- 因为SSL协议设计初衷是对Web站点及网上交易进行安全性保护，使消费者明白正在和谁进行交易要比使商家知道谁正在付费更为重要，为了不致于由于安全协议的使用而导致网络性能大幅下降， SSL协议并不是默认地要求进行客户鉴别，这样做虽然有悖于安全策略，但却促进了SSL的广泛应用。
- 针对这个问题，可在必要的时候配置SSL协议，使其选择对客户端进行认证鉴别。
- SSL协议需要在握手之前建立TCP连接，因此不能对UDP应用进行保护。如果要兼顾UDP协议层之上的安全保护，可以采用IP层的安全解决方案。
- 由于SSL只对应用数据进行保护，数据包的IP头和TCP头仍然暴露在外，通过检查没有加密的IP源和目的地址以及TCP端口号或者检查通信数据量，一个通信分析者依然可以揭示哪一方在使用什么服务，有时甚至揭露商业或私人关系的秘密。
- 除非SSL的工程实现大部分驻留在硬件中，否则主密钥将会存留在主机的主存储器中，这就意味着任何可以读取SSL进程存储空间的攻击者都能读取主密钥，因此，不可能面对掌握机器管理特权的攻击者而保护SSL连接，这个问题要依靠用户管理策略来解决。
TO BE CONTINUE......