Http协议精华一页纸

Posted 2021-04-24 一页纸世界

1、应用层协议HTTP

---

Http是使用最广泛的协议，基于 TCP/IP 协议进行数据传输;http 虽然是文本协议，解析和传输稍慢，但安全便捷，在穿越防火墙等很多方面有其优势；从只是网站浏览，到WebService，再到SOA的RestFul，作用越来越重要

I、URL 与 URI
关于URL和URI的区别，网上有很多，可以百度
Http请求的URL 格式如下：
schema://host[:port#]/path/..../[?query-string][#anchor]
协议类型 主机 端口 资源路径 查询字符串 锚(熟悉js的可能了解，可以理解成页内链接)

II、无连接的协议
Http协议虽然是基于TCP协议的协议，但却是一种无连接、无状态的协议，一次响应结束，就关闭其连接。无连接有其好处，特别是对于HTTP这种大量浏览各种数据的，而且面对的是终端用户，如果维持其链接，就会把资源耗尽。
但无连接也有其弊端，就是无法缓存用户状态。解决方法

Session - 针对同一个浏览器中多次访问是同一个Session（只认ID不认人）； 不同浏览器，同一个浏览器的不同进程是不同的Session
session 记录

a、使用 cookie记录sessionid（服务端发来的相应消息），然后请求时加上cookie内容
HTTP/1.1 302 Found
Location: http://www.google.com/intl/zh-CN/
Set-Cookie: JSESSIONID=0565f77e132de138 expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com
Content-Type: text/html
b、通过URL重写，在不支持cookie 的基础上，每次请求加上 ;jsessionid=xxxxxxxx 的参数，比如http://...../xxx;jsessionid=ByOK3vjFD75aPnrF7C2H

2、报文

---

I、报文例子
请求报文：
GET / HTTP/1.1
Host: localhost:9999
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: zh-CN,zh;q=0.8

响应报文：
HTTP/1.1 400 Bad Request
Server: nginx/1.9.4
Date: Wed, 19 Jul 2017 03:11:43 GMT
Content-Type: text/html
Content-Length: 172
Connection: close

II、起始行 - 核心信息
a、请求起始行 - 描述了HTTP协议的几种方式、请求的资源、HTTP 版本
<method><url><version>
GET / HTTP/1.1

b、响应起始行 - 描述了HTTP版本、响应码(成功与否)、响应码描述
<version><code><desc>
HTTP/1.1 400 Bad Request

c、方法
GET – 获取文档
HEAD – 获取文档的首部
POST – 发送数据给服务器
PUT – 将请求的主体存储在服务器上
TRACE – 报文追踪
OPTIONS – 服务器上可执行的方法
DELETE – 删除文档

GET/POST 都可以传送数据到服务器，只是GET受URL长度限制传送数据优先，不同浏览器限制不同，一般不建议传输超过 2048 个字节的
PUT/DELETE/GET/POST 都是 restFul 开发所需要的方法

d、状态码
100 – 199 信息提示
200 – 299 成功
300 – 399 重定向
400 – 499 客户端失败
500 – 599 服务端失败

典型状态码
200 OK
301/302 Moved Permanently/temporarily 重定向,前者是永久重定向,后者是临时重定向
303 See Other 重定向到其他资源
400 Bad Request -- 有个经典面试题, GET 后面如果不是跟着资源，而是跟着服务器，会怎么样。答案就是400 错误的请求，服务端无法解析
403 Forbidden
404 Not Found
500 Internal Server Error -- 服务器遇到无法预知的错误，一般在服务器出现问题时，会出现
503 Server Unavailable -- 服务器暂时无法服务

III、首部
客户端和服务端进行交互约束的一些配置项，都是 key - value 结构
a、通用首部 - 适用于请求和响应
Connection: keep-alive 
-- 非常重要的设置，支持长连接，多次访问可以不用重复建链，对提高Web访问非常重要，除此之外，还有长连接的超时等相关配置
Cache-Control: max-age=0
-- 非常重要的配置，提示 客户端，是否需要读缓存，多长时间内可以不要访问服务器

b、请求首部
Host: localhost:9999 -- 主机信息
Accept及其相关的一些参数 -- 客户端支持的类型、字符集、编码、语言等等
refer 跟踪请求来源，比如是从搜索引擎链接来的，还可以用作防盗链
Range 用于断点续传，告诉服务端从哪里开始
If-Modified-Since 从某个时间开始没修改，这个参数结合其他首部实现一个非常重要的优化

If-Modified-Since & Last-Modified & 状态码304 实现客户端缓存，减少服务端压力
流程是：
i、服务端在返回资源时，填写实体 Last-Modified 时间
ii、浏览器收到响应时，登记 该时间
iii、浏览器再次请求时，把时间填入 If-Modified-Since
iv、服务端检查是否修改过，没有则返回 304 状态码
v、浏览器收到 304，从本地加载数据

这个优化，节省了大量的网络流量，速度提升可能会数倍

c、响应首部
Location -- 通知客户端重定向新的url
Server -- 服务器信息
其他一些认证、代理信息

d、实体首部
Content 相关首部，包括返回的实体类型 Content-Type 、实体内容长度 Content-Length、语言编码等等
-- Content-Length 这个非常重要，不然浏览器无法判断报文是否结束，缓存代理也无法进行缓存；早期的http采用连接关闭来判断结束，但无法区分异常关闭；
所以，必须要有长度知道报文结束，特别是针对Keep-alive长连接，只有一种情况例外 Transfer-Encoding:chunked，分块传送，每块自带长度。
也就是说，发回客户端的数据，要么确切知道长度用 Content-Length；要么设定 Transfer-Encoding:chunked，每发一个消息块之前，设定一个长度
Expires -- 过期时间，通知代理和浏览器失效的时间
Last-Modified -- 最后修改时间，见前文描述

e、非HTTP 1.1标准首部
Set-Cookie -- 服务端在用户浏览器设置 Cookie 缓存
Set-Cookie：键值对; path= ; domain= ; expires= ; [secure]
http://blog.csdn.net/lijing198997/article/details/9378047
Cookie -- 在服务端设置 cookie后，浏览器后面每个请求都会把 cookie 携带发给服务端 (自己写js 也可以)

3、缓存

---

服务端 建议 客户端 进行数据缓存，分散流量，优化网站

I、页面级的缓存
a、第一级控制 直接缓存 Cache-Control:
private 当前窗口 回车|后退 只有第一次请求访问服务器；刷新则重新获取
no-cache 不缓存
max-age 缓存多少秒内访问本地； 刷新重新访问
must-revalidate 配置使用，本地过期后必须访问服务器进行有效性检验

一般对于静态文件，比如图片和css 这些可以设置max-age超长日期
Cache-Control:max-age=315360000

b、第二级控制 变化判断 Last-Modified
具体参见前面描述，根据资源是否变化来控制是否读取
和前面直接缓存比，这个需要多向服务端请求一次，只是不需要发送 实体数据

http://developer.51cto.com/art/201611/520324.htm

II、数据缓存
a、cookie
服务端通过 Set-Cookie；客户端把Cookie 带到服务端

b、H5支持的 localStorage/sessionStorage
可以通过js 进行存储，然后 ajax 等返回记录结果
localStorage[key]= value;
localStorage.setItem(key, value);

c、H5浏览器支持的 本地数据库
var db = openDatabase('databasename','version','desc',size,callback);
db.transaction(function (tx){
tx.executeSql(sql);
});
tx.executeSql(sql, [], function(tx,results){
results.rows.item(i).column
}

III、离线文件
让客户端缓存一些文件 *.appcache

具体参见本博《H5 精华一页纸》

4、交互

---

I、Pull VS Push
正常的 HTTP 访问都是 pull 方式，客户端从服务端拉取数据;这样就需要 不断轮询刷新服务端，给服务端也带来了较大的压力；
如果能够服务端主动推送建链以后，这样效率就高了

II、SSE | WebSocket
H5新增了模式， 和消息中间件一样 提供了 推 模式，即一旦建立连接后，数据由服务端推送到客户端，要实现这部分功能至少需要如下基础：
a、服务器和客户端(浏览器) 要保持长链接 - HTTP1.1 / HTTP2.0 keep-alive
b、服务器要不断给客户端发送数据 - 占用线程
一般服务器给客户端的响应有几种方式，一种是基于 IO的，请求的Servlet 给客户端发送数据；另一种基于NIO，只有一个线程，服务端轮询给客户端发送数据；通过定时器不断发送数据

具体参见本博《H5 精华一页纸》

5、安全

---

http 的协议文本协议，也就是说所有信息，都是文本传输，如果 传输 用户、密码等重要信息怎么办？
I、应用加密关键数据
可以用自定义加密
单向散列 哈希函数，比如MD5,SHA
对称加密算法 DES
非对称加密 RSA 算法，有公钥和私钥

另外，通过加盐，避免彩虹表暴力破解

II、HTTPS
HTTPS 在 HTTP - TCP 之间增加了一层协议 SSL，算法就是上文的RSA 等算法；对传输内容整体进行加密
a、步骤
在tcp 建链成功后，再进行 SSL 协议建链
通过发送方利用 公钥 进行加密
接收方 利用 私钥进行解密

https://www.zhihu.com/question/21518760

b、CA
公钥 大家都知道，可能会被篡改、模仿，还是有风险。所以有专门的结构审核签名，只有这个签发的CA证书才能使用。

III、跨域问题
跨域是浏览器对js直接访问同源的一种限制； 域名|端口|协议 不一致的都限制访问。解决方法
a、最常用的就是 jsonp
jsonp的原理是绕过 浏览器对跨域的限制；即浏览器本身可以跨域下载js；这样通过 远端域的 js访问自己的数据就可以了。后来演变成根据 url get 请求自动生成js
i、本域调用端 设置下载 js (任何src 下载的都可以) url -- 在该url里面设置 远端服务名和 get请求参数
比如 "http://www.xxx.com/service?param=xxx&callback=localFunction
ii、远端服务器收到下载请求, 首先根据参数调用自己的服务, 并生成一个js 文件(可执行代码段) -- 该文件包含 调用 localFunction 代码
iii、下载js文件(可执行代码段)后, 并执行 该代码
http://kb.cnblogs.com/page/139725/

b、其他共享数据的方式
window.name
document.domain
localStorage
这些方法和 jsonp 思想有重复的地方，就是 通过远端自己的js 把数据写在同一个 应用缓存中； 本端的js可以通过这个缓存来获取数据

c、服务端代理
其实 b 的共享数据可以认为是 客户端代理的方式； 可以通过服务端获取数据来代理返回给客户端

d、远端消息首部设置???
Access-Control-Allow-Origin: *

e、postMessage???
具体参见下面的博文
http://itoss.me/2016/12/31/%E8%AF%B4%E8%AF%B4%E8%B7%A8%E5%9F%9F%E9%82%A3%E4%BA%9B%E4%BA%8B%E5%84%BF/