HTTP

这是我参与「第五届青训营」伴学笔记创作活动的第 14 天

特点

支持客户/服务器模式
简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快
灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间
无状态：HTTP协议无法根据之前的状态进行本次的请求处理

状态码

状态码第一位数字决定了不同的响应状态，有如下：

1 表示消息
2 表示成功
3 表示重定向
4 表示请求错误
5 表示服务器错误

下面给出一些常见状态码的适用场景：

100：客户端在发送POST数据给服务器前，征询服务器情况，看服务器是否处理POST的数据，如果不处理，客户端则不上传POST数据，如果处理，则POST上传数据。常用于POST大数据传输
200：客户端请求成功
206：一般用来做断点续传，或者是视频文件等大文件的加载
301：永久重定向会缓存。新域名替换旧域名，旧的域名不再使用时，用户访问旧域名时用301就重定向到新的域名
302：临时重定向不会缓存，常用于未登陆的用户访问用户中心重定向到登录页面
304：协商缓存，告诉客户端有缓存，直接使用缓存中的数据，返回页面的只有头部信息，是没有内容部分
400：参数有误，请求无法被服务器识别
403：告诉客户端进制访问该站点或者资源，如在外网环境下，然后访问只有内网IP才能访问的时候则返回
404：服务器找不到资源时，或者服务器拒绝请求又不想说明理由时
503：服务器停机维护时，主动用503响应请求或 nginx 设置限速，超过限速，会返回503
504：网关超时

method

一览

GET 请求一个指定资源的表示形式. 使用 GET 的请求应该只被用于获取数据
POST 用于将实体提交到指定的资源，通常导致在服务器上的状态变化或副作用
PUT 用请求有效载荷替换目标资源的所有当前表示
DELETE 删除指定的资源
HEAD 请求一个与 GET 请求的响应相同的响应，但没有响应体
CONNECT 建立一个到由目标资源标识的服务器的隧道。
OPTIONS 用于描述目标资源的通信选项。
TRACE 沿着到目标资源的路径执行一个消息环回测试。
PATCH 用于对资源应用部分修改。

不修改服务器数据的方法叫安全的。

同样的请求多次执行的效果是一致的、服务器效果是一致的，就叫做幂等

get和post区别

POST比GET 安全，因为数据在地址栏上不可见

然而，从传输的角度来说，他们都是不安全的，因为HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。只有使用HTTPS才能加密安全
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）

对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok

请求头

字段名	说明	示例
Accept	能够接受的回应内容类型（Content-Types）	Accept: text/plain
Accept-Charset	能够接受的字符集	Accept-Charset: utf-8
Accept-Encoding	能够接受的编码方式列表	Accept-Encoding: gzip, deflate
Accept-Language	能够接受的回应内容的自然语言列表	Accept-Language: en-US
Authorization	用于超文本传输协议的认证的认证信息	Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
Cache-Control	用来指定在这次的请求/响应链中的所有缓存机制都必须遵守的指令	Cache-Control: no-cache
Connection	该浏览器想要优先使用的连接类型	Connection: keep-alive Connection: Upgrade
Cookie	服务器通过 Set- Cookie （下文详述）发送的一个超文本传输协议Cookie	Cookie: $Version=1; Skin=new;
Content-Length	以八位字节数组（8位的字节）表示的请求体的长度	Content-Length: 348
Content-Type	请求体的多媒体类型	Content-Type: application/x-www-form-urlencoded
Date	发送该消息的日期和时间	Date: Tue, 15 Nov 1994 08:12:31 GMT
Expect	表明客户端要求服务器做出特定的行为	Expect: 100-continue
Host	服务器的域名(用于虚拟主机 )，以及服务器所监听的传输控制协议端口号	Host: en.wikipedia.org:80 Host: en.wikipedia.org
If-Match	仅当客户端提供的实体与服务器上对应的实体相匹配时，才进行对应的操作。主要作用时，用作像 PUT 这样的方法中，仅当从用户上次更新某个资源以来，该资源未被修改的情况下，才更新该资源	If-Match: "737060cd8c284d8af7ad3082f209582d"
If-Modified-Since	允许在对应的内容未被修改的情况下返回304未修改	If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-None-Match	允许在对应的内容未被修改的情况下返回304未修改	If-None-Match: "737060cd8c284d8af7ad3082f209582d"
If-Range	如果该实体未被修改过，则向我发送我所缺少的那一个或多个部分；否则，发送整个新的实体	If-Range: "737060cd8c284d8af7ad3082f209582d"
Range	仅请求某个实体的一部分	Range: bytes=500-999
User-Agent	浏览器的浏览器身份标识字符串	User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0
Origin	发起一个针对跨来源资源共享的请求	Origin: www.example-social-network.com

通过配合请求头和响应头，可以满足一些场景的功能实现：

协商缓存

利用的是【Last-Modified，If-Modified-Since】和【ETag、If-None-Match】这两对请求头响应头来管理的

Last-Modified 表示本地文件最后修改日期，浏览器会在request header加上If-Modified-Since（上次返回的Last-Modified的值），询问服务器在该日期后资源是否有更新，有更新的话就会将新的资源发送回来

Etag就像一个指纹，资源变化都会导致ETag变化，跟最后修改时间没有关系，ETag可以保证每一个资源是唯一的

If-None-Match的header会将上次返回的Etag发送给服务器，询问该资源的Etag是否有更新，有变动就会发送新的资源回来

而强制缓存不需要发送请求到服务端，根据请求头expires和cache-control判断是否命中强缓存

会话状态

cookie，类型为「小型文本文件」，指某些网站为了辨别用户身份而储存在用户本地终端上的数据，通过响应头set-cookie决定

作为一段一般不超过 4KB 的小型文本数据，它由一个名称（Name）、一个值（Value）和其它几个用于控制 Cookie有效期、安全性、使用范围的可选属性组成

Cookie 主要用于以下三个方面：

会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
个性化设置（如用户自定义设置、主题等）
浏览器行为跟踪（如跟踪分析用户行为等

HTTP 协议的场景

发起HTTP

浏览器：AJAX-XHR和一些方法；AJAX-Fetch

axios库，对请求进行进一步封装

优化HTTP

加速【http2 CDN动态加速 CDN预解析网络预连接域名压缩 https性能优化】

稳定性【重试缓存数据安全】

HTTP版本

HTTP1.0

HTTP协议的第二个版本，第一个在通讯中指定版本号的HTTP协议版本

HTTP 1.0 浏览器与服务器只保持短暂的连接，每次请求都需要与服务器建立一个TCP连接

服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求

简单来讲，每次与服务器交互，都需要新开一个连接

最终导致，一个html文件的访问包含了多次的请求和响应，每次请求都需要创建连接、关系连接

这种形式明显造成了性能上的缺陷

如果需要建立长连接，需要设置一个非标准的Connection字段 Connection: keep-alive

HTTP1.1

在HTTP1.1中，默认支持长连接（Connection: keep-alive），即在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟

建立一次连接，多次请求均由这个连接完成

同时，HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间

同时，HTTP1.1在HTTP1.0的基础上，增加更多的请求头和响应头来完善的功能

引入了更多的缓存控制策略，如If-Unmodified-Since, If-Match, If-None-Match等缓存头来控制缓存策略
引入range，允许值请求资源某个部分
引入host，实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点

并且还添加了其他的请求方法：put、delete、options

HTTP2.0

而HTTP2.0在相比之前版本，性能上有很大的提升，如添加了一个特性：

多路复用

复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”
二进制分帧

采用二进制格式传输数据，而非 HTTP 1.x的文本格式，解析起来更高效

将请求和响应数据分割为更小的帧，并且它们采用二进制编码

HTTP2中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流

每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装，这也是多路复用同时发送数据的实现条件
首部压缩

在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送
服务器推送

允许服务端推送资源给客户端

服务器会顺便把一些客户端需要的资源一起推送到客户端，如在响应一个页面请求中，就可以随同页面的其它资源

免得客户端再次创建连接发送请求到服务器端获取

这种方式非常合适加载静态资源

HTTPS

定义

HTTP 通信使用明文（不加密），内容可能被窃听；不验证通信方的身份，因此有可能遭遇伪装，这并不安全。而HTTPS出现正是为了解决HTTP不安全的特性

为了保证这些隐私数据能加密传输，让HTTP运行安全的SSL/TLS协议上，即 HTTPS = HTTP + SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密

SSL 协议位于TCP 协议与各种应用层协议（如HTTP）之间，浏览器和服务器在使用 SSL 建立连接时需要选择一组恰当的加密算法来实现安全通信，为数据通讯提供安全支持

建立连接的过程

首先客户端通过URL访问服务器建立SSL连接
服务端收到客户端请求后，会将网站支持的证书信息（证书中包含公钥）传送一份给客户端
客户端的服务器开始协商SSL连接的安全等级，也就是信息加密的等级
客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站
服务器利用自己的私钥解密出会话密钥
服务器利用会话密钥加密与客户端之间的通信

区别

HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理，相对更安全
HTTP 和 HTTPS 使用连接方式不同，默认端口也不一样，HTTP是80，HTTPS是443
HTTPS 由于需要设计加密以及多次握手，性能方面不如 HTTP
HTTPS需要SSL，SSL 证书需要钱，功能越强大的证书费用越高

加密详解

类型：

对称加密：采用协商的密钥对数据加密
非对称加密：实现身份认证和密钥协商
摘要算法：验证信息的完整性
数字签名：身份验证

对称加密

对称加密指的是加密和解密使用的秘钥都是同一个，是对称的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性

非对称加密

非对称加密，存在两个秘钥，一个叫公钥，一个叫私钥。两个秘钥是不同的，公钥可以公开给任何人使用，私钥则需要保密

公钥和私钥都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密

混合加密

在HTTPS通信过程中，采用的是对称加密+非对称加密，也就是混合加密

在对称加密中讲到，如果能够保证了密钥的安全，那整个通信过程就可以说具有了机密性

而HTTPS采用非对称加密解决秘钥交换的问题

具体做法是发送密文的一方使用对方的公钥进行加密处理“对称的密钥”，然后对方用自己的私钥解密拿到“对称的密钥”

上述的方法解决了数据加密，在网络传输过程中，数据有可能被篡改，并且黑客可以伪造身份发布公钥，如果你获取到假的公钥，那么混合加密也并无多大用处，你的数据扔被黑客解决。因此，在上述加密的基础上仍需加上完整性、身份验证的特性，来实现真正的安全，实现这一功能则是摘要算法

摘要算法

实现完整性的手段主要是摘要算法，也就是常说的散列函数、哈希函数

可以理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”

摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性

数字签名

数字签名能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名

原理其实很简单，就是用私钥加密，公钥解密

签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的

地址栏输入 URL 敲下回车后发生了什么

简单的分析，从输入 URL到回车后发生的行为如下：

URL解析——DNS 查询——TCP 连接——HTTP 请求——响应请求——页面渲染

URL解析

首先判断你输入的是一个合法的URL 还是一个待搜索的关键词，并且根据你输入的内容进行对应操作

DNS查询

一级级查询DNS服务器，获得需要的ip

TCP连接

在确定目标服务器服务器的IP地址后，则经历三次握手建立TCP连接

http 请求

当建立tcp连接之后，就可以在这基础上进行通信，浏览器发送 http 请求到目标服务器

请求的内容包括：【请求行、请求头、请求主体】

当服务器接收到浏览器的请求之后，就会进行逻辑操作，处理完成之后返回一个HTTP响应消息，包括：【状态行、响应头、响应正文】

在服务器响应之后，由于现在http默认开始长连接keep-alive，当页面关闭之后，tcp链接则会经过四次挥手完成断开

页面渲染

当浏览器接收到服务器响应的资源后，首先会对资源进行解析：

查看响应头的信息，根据不同的指示做对应处理，比如重定向，存储cookie，解压gzip，缓存资源等等
查看响应头的 Content-Type的值，根据不同的资源类型采用不同的解析方式