HTTP
-
HTTP（Hyper Text Transfer Protocol），译为超文本传输协议
- 是互联网中应用最广泛的应用层协议之一
- 设计HTTP最初的目的是：提供一种发布和接收HTML页面的方法，由URI来标识具体的资源
- 后面用HTTP来传递的数据格式不仅仅是HTML，应用非常广泛
- （为何叫 超文本？因为它传输的数据除了文本还有图片，视频，音频啊_）
-
HTML（ Hyper Text Markup Language）：超文本标记语言
- 用以编写网页
维基百科上的介绍
版本
- 1991年，HTTP/0.9
- 只支持GET请求方法获取文本数据（比如HTML文档），且不支持请求头、响应头等，无法向服务器传递太多信息
- 1996年，HTTP/1.0
- 支持POST、HEAD等请求方法，支持请求头、响应头等，支持更多种数据类型（不再局限于文本数据）
- 浏览器的每次请求都需要与服务器建立一个TCP连接，请求处理完成后立即断开TCP连接
- 1997年，HTTP/1.1（最经典、使用最广泛的版本，目前很多还是用该版本）
- 支持PUT、DELETE等请求方法
- 采用持久连接（Connection: keep-alive），多个请求可以共用同一个TCP连接
- 2015年，HTTP/2.0 （稳定可升级）
- 2018年，HTTP/3.0 （开发中）
标准
- HTTP的标准
- 由万维网协会（W3C）、互联网工程任务组（IETF）协调制定，最终发布了一系列的RFC
- RFC（Request For Comments，可以译为：请求意见稿）
- 中国的RFC
- 1996年3月，清华大学提交的适应不同国家和地区中文编码的汉字统一传输标准被IETF通过为RFC 1922
- 成为中国大陆第一个被认可为RFC文件的提交协议
报文格式
ABNF
- ABNF（Augmented BNF）
- 是BNF（Backus-Naur Form，译为：巴科斯-瑙尔范式）的修改、增强版
- 在RFC 5234中表明：ABNF用作internet中通信协议的定义语言
- ABNF是最严谨的HTTP报文格式描述形式，脱离ABNF谈论HTTP报文格式，往往都是片面、不严谨的
- 关于HTTP报文格式的定义
ABNF - 核心规则
报文格式 - 整体
报文格式 - request-line、status-line
报文格式 - header-filed、message-body
URL的编码
- URL中一旦出现了一些特殊字符（比如中文、空格），需要进行编码
- 在浏览器地址栏输入URL时，是采用UTF-8进行编码
- 比如
Xshell + telnet
- 安装一个Xshell（安全终端模拟软件），在Xshell中使用telnet
- 可以直接面向HTTP报文与服务器交互
- 可以更清晰、直观地看到请求报文、响应报文的内容
- 可以检验请求报文格式的正确与否
请求方法
-
RFC 7231, section 4: Request methods：描述了8种请求方法
-
GET、HEAD、POST、PUT、DELETE、CONNECT、OPTIONS、TRACE
-
RFC 5789, section 2: Patch method：描述了PATCH方法
-
GET：常用于读取的操作，请求参数直接拼接在URL的后面（浏览器对URL是有长度限制的）
-
POST：常用于添加、修改、删除的操作，请求参数可以放到请求体中（没有大小限制）
-
HEAD：请求得到与GET请求相同的响应，但没有响应体
- 使用场景举例：在下载一个大文件前，先获取其大小，再决定是否要下载。以此可以节约带宽资源
-
OPTIONS：用于获取目的资源所支持的通信选项，比如服务器支持的请求方法
- OPTIONS * HTTP/1.1
-
PUT：用于对已存在的资源进行整体覆盖
-
PATCH：用于对资源进行部分修改（资源不存在，会创建新的资源）
-
DELETE：用于删除指定的资源
-
TRACE：请求服务器回显其收到的请求信息，主要用于HTTP请求的测试或诊断
-
CONNECT：可以开启一个客户端与所请求资源之间的双向沟通的通道，它可以用来创建隧道（tunnel）
- 可以用来访问采用了 SSL (HTTPS) 协议的站点
头部字段（Header Field）
- 头部字段可以分为4种类型
- 请求头字段（Request Header Fields）
- 有关要获取的资源或客户端本身信息的消息头
- 响应头字段（Response Header Fields）
- 有关响应的补充信息，比如服务器本身（名称和版本等）的消息头
- 实体头字段（Entity Header Fields）
- 有关实体主体的更多信息，比如主体长度（Content-Length）或其MIME类型
- 通用头字段（General Header Fields）
- 同时适用于请求和响应消息，但与消息主体无关的消息头
- 请求头字段（Request Header Fields）
请求头字段
响应头字段
状态码（Status Code ）
- 在RFC 2616 10.Status Code Definitions规范中定义
- 状态码指示HTTP请求是否已成功完成
- 状态码可以分为5类
- 信息响应：100~199
- 成功响应：200~299
- 重定向：300~399
- 客户端错误：400~499
- 服务器错误 ：500~599
常见状态码
-
100 Continue
- 请求的初始部分已经被服务器收到，并且没有被服务器拒绝。客户端应该继续发送剩余的请求，如果请求已经完 成，就忽略这个响应
- 允许客户端发送带请求体的请求前，判断服务器是否愿意接收请求（服务器通过请求头判断）
- 在某些情况下，如果服务器在不看请求体就拒绝请求时，客户端就发送请求体是不恰当的或低效的
-
200 OK：请求成功
-
302 Found：请求的资源被暂时的移动到了由Location头部指定的URL上
-
304 Not Modified：说明无需再次传输请求的内容，也就是说可以使用缓存的内容
-
400 Bad Request：由于语法无效，服务器无法理解该请求
-
401 Unauthorized：由于缺乏目标资源要求的身份验证凭证
-
403 Forbidden：服务器端有能力处理该请求，但是拒绝授权访问
-
404 Not Found：服务器端无法找到所请求的资源
-
405 Method Not Allowed：服务器禁止了使用当前HTTP方法的请求
-
406 Not Acceptable：服务器端无法提供与Accept-Charset以及Accept-Language指定的值相匹配的响应
-
408 Request Timeout：服务器想要将没有在使用的连接关闭
- 一些服务器会在空闲连接上发送此信息，即便是在客户端没有发送任何请求的情况下
-
500 Internal Server Error：所请求的服务器遇到意外的情况并阻止其执行请求
-
501 Not Implemented：请求的方法不被服务器支持，因此无法被处理
- 服务器必须支持的方法（即不会返回这个状态码的方法）只有 GET 和 HEAD
-
502 Bad Gateway：作为网关或代理角色的服务器，从上游服务器（如tomcat）中接收到的响应是无效的
-
503 Service Unavailable：服务器尚未处于可以接受请求的状态
- 通常造成这种情况的原因是由于服务器停机维护或者已超载
Form提交 - 常用属性
-
action：请求的URI
-
method：请求方法（GET、POST）
-
enctype：POST请求时，请求体的编码方式
-
application/x-www-form-urlencoded（默认值）
- 用&分隔参数，用=分隔键和值，字符用URL编码方式进行编码
-
multipart/form-data
- 文件上传时必须使用这种编码方式
-
multipart/form-data
-
请求头
- Content-Type: multipart/form-data; boundary=xxx
说明
-
boundary
- 分界符，用于对参数的分隔
- 参数开头 --boundary，注意前面必需要有2个 -- 符号
- 最后以 --boundary-- 结束
请求示例
同源策略
- 浏览器有 同源策略（Same-Origin Policy）
- 它规定了：默认情况下，AJAX请求只能发送给同源的URL
- 同源是指3个相同：协议、域名（IP）、端口
- 当Ajax请求如果发现不是同源的URL，就会被拦截，这就是所谓的跨域
- img、script、link、iframe、video、audio等标签不受同源策略的约束
跨域
- 解决Ajax跨域请求的常用方法
- CORS（Cross-Origin Resource Sharing），跨域资源共享
- JSONP（以前比较旧的处理方式）
- 服务端代理
- Nginx代理
CORS
- CORS的实现需要客户端和服务器同时支持
- 客户端
- 所有的浏览器都支持（IE至少是IE10版本及以上）
- 服务器
- 需要添加响应头信息（Access-Conrol-Allow-Origin）
- 告诉浏览器，这是一个允许跨域访问的请求
- 客户端
JSONP
- 使用 script 标签加载一个接口地址，接口返回的是js代码，并主动调用页面中的指定方法
- 现在基本不使用
服务端代理
- 后端专门写一个服务接收前端的URL参数，这个请求由后端去请求，得到数据后再返回给前端，因为后端是不会有跨域的限制
- 后端接口和前端需要在同源URL中
- 使用麻烦，基本不使用
Nginx代理
- 前端请求与Nginx那边协商好的需要跨域的一个地址，但是是一个同源的URL地址
- Nginx接到这个请求后，将该地址再转发到原始的需要跨域的地址中
- 和上面的服务端代码类似，但配置更简单
- 推荐使用
Cookie
- 用于在客户端（浏览器）存储数据，小缓存
- 容量小
- 服务器和客户端都可以 设置Cookie数据，都可以去修改
- 客户端是直接去使用API设置
- 服务端是通过响应头中的 Set-Cookie 参数设置
- 有效期
- 默认不设置有效期，就是 会话级别的，当浏览器一关，就会清空
- 设置了有效期，当有效期一过，也会失效，这种浏览器关了是不会清空的
- 获取范围
- 同域名IP，不同端口也是可以共享的
- t1.baidu.com 与 t2.baidu.com 默认是不能共享的，因为不是同一个域名
- 如果给 domian 设置为 .baidu.com 就能两个域名共享cookie了
- 上级目录设置的cookie，下级目录可以获取到，而下级目录设置的cookie，上级目录不能获取
- 如何让上级获取到下级目录设置的cookie呢
- 设置path属性 document.cookie = "key=value;path=/"
Session
- 会话，用于在服务器存储与客户端相关的数据
- 它能识别客户端的请求来自哪个会话
建立用户会话
-
当用户登录成功后，服务器会生成一个唯一的 ID（SeesionID）作为Key保存在Session中，value就是该用户信息相关参数
-
然后返回响应头的时候，在 Set-Cookie 中设置 JSEESIONID=XXX
-
这样就将这个SessionID保存到客户端了
-
下次客户端再发起请求的时候，就会将Cookie中的这个 JSEESIONID 一起发给后端
-
后端收到后去 Session 中查询这个KEY，就能知道这次请求是哪个用户的了
缓存（Cache）
-
Cache的发音和Cash（现金）一样
-
实际上，HTTP的缓存机制远远比上图的流程要复杂
-
通常会缓存的情况是:GET请求＋静态资源（比如HTML、CSS、JS、图片等)
-
Ctrl + F5:可以强制刷新缓存
缓存 - 响应头
- Pragma:作用类似于Cache-Control，HTTP/1.0的产物
- Expires:缓存的过期时间(GMT格式时间)，HTTP/1.0的产物
- 问题：过期时间是和客户端时间比较的，每个人的电脑时间都有可能不一样，所以缓存不靠谱
- Cache-Control: 设置缓存策略
- no-storage: 不缓存数据到本地
- public: 允许用户、代理服务器缓存数据到本地
- private: 只允许用户缓存数据到本地
- max-age: 缓存的有效时间(多长时间不过期)，单位秒
- no-cache: 每次需要发请求给服务器询问缓存是否有变化，再来决定如何使用缓存
- 优先级: Pragma > Cache-Control（ETag > Last-Modified） > Expires
缓存 - 请求头
- lf-None-Match
- 如果上一次的响应头中有ETag，就会将ETag的值作为请求头的值
- 如果服务器发现资源的最新摘要值跟lf-None-Match不匹配，就会返回新的资源（200 OK)
- 否则，就不会返回资源的具体数据(304 Not Modified)
- lf-Modified-Since
- 如果上一次的响应头中没有ETag，有Last-Modified，就会将Last-Modified的值作为请求头的值
- 如果服务器发现资源的最后一次修改时间晚于lf-Modified-Since，就会返回新的资源(200 OK)
- 否则，就不会返回资源的具体数据(304 Not Modified)
缓存 - Last-Modified vs ETag
- Last-Modified的缺陷
- 只能精确到秒级别，如果资源在1秒内被修改了，客户端将无法获取最新的资源数据
- 如果某些资源被修改了（最后一次修改时间发生了变化)，但是内容并没有任何变化
- 会导致相同数据重复传输，没有使用到缓存
- ETag可以办到
- 只要资源的内容没有变化，就不会重复传输资源数据
- 只要资源的内容发生了变化，就会返回最新的资源数据给客户端
缓存的使用流程图
代理服务器 （Proxy Server）
- 特点
- 本身不生产内容
- 处于中间位置转发上下游的请求和响应
- 面向下游的客户端：它是服务器
- 面向上游的服务器：它是客户端
正向代理、反向代理
- 正向代理：代理的对象是客户端
- 如：浏览器中的HTTP代理
- 反向代理：代理的对象是服务器
- 如：Nginx代理
正向代理 - 作用
- 隐藏客户端身份
- 绕过防火墙（突破访问限制）
- Internet访问控制
- 数据过滤
- ...
反向代理 - 作用
- 隐藏服务器身份
- 安全防护
- 负载均衡
抓包工具的原理
- Fiddler、Charles等抓包工具的原理：在客户端启动了正向代理服务
- 需要注意的是
- Wireshark的原理是：通过底层驱动，拦截网卡上流过的数据
代理服务器 相关的头部字段
- Via：追加经过的每一台代理服务器的主机名（或域名）
- X-Forwarded-For：追加请求方的IP地址
- X-Real-IP：客户端的真实IP地址
CDN
- CDN（Content Delivery Network或Content Distribution Network），译为：内容分发网络
- 利用最靠近每位用户的服务器 更快更可靠地将音乐、图片、视频等资源文件（一般是静态资源）传递给用户
-
使用前后对比
-
CDN运营商在全国、乃至全球的各个大枢纽城市都建立了机房
- 部署了大量拥有高存储高带宽的节点，构建了一个跨运营商、跨地域的专用网络
-
内容所有者向CDN运营商支付费用，CDN将其内容交付给最终用户
CDN DNS服务器
-
CDN 有自己的DNS服务器，为了更快速的解析IP给用户
-
正常没有CDN的请求
- 使用了CDN的请求
- 当浏览器向DNS服务器查询的时候，DNS服务器会将该查询指向到离你最近的一台CDN DNS服务器
