这是我参与「第四届青训营」笔记创作活动的第3天

一、初识HTTP

输入url -> browser进程处理输入信息 -> 浏览器内核向服务器发起请求 -> 浏览器内核读取响应 -> 浏览器内核进行渲染 -> browser进程页面加载完成

Hyper Text Transfer Protocol （HTTP）超文本传输协议
他是应用层协议，基于传输层的TCP协议
请求、响应
简单可扩展（可以自定义请求头，只要客户端服务端之间可以理解）
无状态

二、协议分析

发展历程

报文结构

HTTP/1.1

如图，可以看到请求和响应的请求头、返回的状态码、等等

Safe（安全的）：不会修改服务器数据的方法，如读数据 GET、HEAD、OPTIONS等
Idempotent（幂等）：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的，所有safe的方法都是Idempotent的如GET、HEAD、OPTIONS、PUT、DELETE等

状态码

200 OK - 客户端请求成功
301 - 资源（网页等）被永久转移到了其它URL
302 - 临时跳转
401 - Unauthorized - 请求未经授权
404 - 请求资源不存在，可能是输入了错误的URL
500 - 服务器内部发生了不可预期的错误
504 Gateway Timeout - 网关或者代理的服务器无法在规定的时间内获得想要的响应

RESTful API

一种API设计风格：REST - Representational State Transfer

每一个URI代表—种资源
客户端和服务器之间，传递这种资源的某种表现层
客户端通过HTTP method，对服务器端资源进行操作，实现"表现层状态转化"。

常用请求头

常用响应头

缓存

1.强缓存

本地有了直接用就好了

（1）Expires（到期时间），时间戳

（2）Cahce-Control

<1>可缓存性

no-cache：协商缓存验证
no-store：不使用任何缓存
public、private等

<2>到期

max-age：单位是秒，存储的最大生存周期，相对于请求的时间

<3>重新验证*重新加载

must-revalidate：一旦资源过期，在成功向原始服务器验证之前，不能使用）（）

2.协商缓存

与Server端要通信，再确定要不要用它

Etag/If-None-Match：资源的特定版本的标识符，类似于指纹
Last-Modified/If-Modified-Since：最后的修改时间。（绝对的）

Cookie Set-Cookie - response

发展

HTTP/2概述：更快、更稳定、更简单

（1）帧(frame)

HTTP/2通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。
1.0传输的是文本，而2中传的则是二进制数据，效率更高。并有新的压缩算法。

（2）消息：与逻辑请求或响应消息对应的完整的一系列帧。

（3）数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。

交错发送，接受方重组织。

（4）HTTP/2连接都是永久的，而且仅需要每个来源一个连接

（5）流控制：阻止发送方向接收方发送大量数据的机制

（6）服务器推送

HTTPS概述

HTTPS : Hypertext Transfer Protocol Secure
经过TSL/SSL加密
对称加密：加密和解密都是使用同一个密钥
非对称加密：加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）

三、常见场景分析

静态资源

以今日头条为例，打开网络面板查看其请求，找到css文件的请求。

可以看到返回的状态码为200，那么是不是真的发起了请求呢（旁边的括号就说了，从磁盘缓存）

由上图响应头，可以看出：

（1）缓存策略？

<1>强缓存（max-age=xxxxx）

Cache-control：换算一下，1年

（1）其他信息？

允许所有域名访问（access-control-allow-origin）
资源类型：css（content-type）

静态资源方案：缓存 + CDN + 文件名hash

（1）CDN：Content Delivery Network

（2）通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务

登陆 - 跨域

跨域问题，导致了请求方法为OPTION

协议、主机名、端口任意一者不同都会出现跨域问题（HTTP的默认端口号443）

解决跨域问题

（1）跨源资源共享（CORS）（ Cross-Origin Resource Sharing ）

跨源资源共享 (CORS)（或通俗地译为跨域资源共享）是一种基于 HTTP 头的机制，该机制通过允许服务器标示除了它自己以外的其它origin（域，协议和端口），这样浏览器可以访问加载这些资源。跨源资源共享还通过一种机制来检查服务器是否会允许要发送的真实请求，该机制通过浏览器发起一个到服务器托管的跨源资源的"预检"请求。在预检中，浏览器发送的头中标示有HTTP方法和真实请求中会用到的头。出于安全性，浏览器限制脚本内发起的跨源HTTP请求。例如，XMLHttpRequest 和 Fetch API 遵循同源策略。这意味着使用这些 API 的 Web 应用程序只能从加载应用程序的同一个域请求 HTTP 资源，除非响应报文包含了正确 CORS 响应头。

预请求：获知服务端是否允许该跨源请求（复杂请求）
相关协议头：access-control-…

（2）代理服务器

同源策略是浏览器的安全策略，不是HTTP的（3）Iframe 诸多不便

鉴权（1）Session + cookie （大部分这种门户网站）

用户发起提交请求给服务器，包括用户名密码等等
服务器处理，鉴别其正确性，若正确则返回Session将其种到cookie（Set-Cookie:session = …）
用户再发送时：GET Cookie:session=…
服务器处理鉴别后返回一些登陆信息的（2)JWT（JSON web token）
服务器本地不会存储
返回的token唯一性，登陆时间短等

（3）SSO：单点登录（Single Sign On）

HTTP使用指南 | 青训营笔记