1.TCP/IP 协议族
报文格式
1 请求：
起始行开头： 请求方法，请求URI，协议版本
请求首部字段：
Host:
Connection: keep-alive
Content-Type: ...
Content-Length: ..
...
隔空行为内容实体：name=xxx&age=22
2 响应：
起始行开头：协议版本，状态码，短语
...
隔空行为内容实体：{}请求方法
GET：获取资源
POST：传输实体主体
HEAD：仅获取报文头部
OPTIONS：询问支持的方法
...
TRACE：追踪路径，用来确认连接过程中发生的一系列操作，但由于容易引发XST（跨站追踪）攻击，就更用不上了
...
CONNECT：要求用隧道协议连接代理，实现用隧道协议进行TCP通信
CONNECT 代理服务器名：端口 HTTP版本
--
以下方法不带验证机制 不建议使用
PUT：传输文件
DELETE：删除文件持久连接
管线化(并行)
编码提升传输效率
1 报文： HTTP通信中的基本单位，8位组字节流
2 压缩内容编码：
gzip: GNU ZIP
compress: UNIX 系统的标准压缩
deflaate: zlib
identity: 不进行编码
3 分块传输编码
十六进制标记块的大小，最后一块使用"0(CR+LF)"标记多种数据的多部分集合
Content-Type: multipart/form-data / multipart/byteranges断点下载
Content-Range: bytes 5000-
若无法完成范围请求，则返回完整的实体内容协商
服务器驱动协商：服务器仅将请求的首部字段作为参考，自动处理内容（不一定是客户想要的）
客户端驱动协商：客户手动选择合适的内容
透明协商： 结合HTTP状态码
注： 302（虽然不允许将POST变成GET，但实际还是变了之后再次发请求），307（强制要求）代理：
透明代理：不更改任何请求报文
非透明代理： 更改报文
缓存代理：将资源缓存网关
与代理类似，但可以改变协议与其他协议通信
利用网关能提高通信的安全：客户端 --> 网关线路上加密隧道
使用SSL等加密手段 保证安全通信
HTTP首部：
- 结构：
首部字段名：字段值（有些字段可以有多个值）
注：当字段重复时，会出现无法确定应用哪个值的情况。不同浏览器采用不同的方式 - 种类：
1 通用首部字段【请求和响应都会使用的首部】
2 请求首部字段【补充附加内容、客户端信息、响应内容和优先级等信息】
3 响应首部字段【补充响应内容，会要求客户端附加额外内容信息等】
4 实体首部字段【请求和响应公用，补充资源内容、更新时间等与实体有关的信息】
1 通用首部字段：
| 首部字段名 | 描述 |
|---|---|
| Cache-Control | 控制缓存行为 |
| Connection | 逐跳首部、连接的管理 |
| Date | 创建报文的日期 |
| Pragma | 报文指令 |
| Trailer | 报文末端的首部一览 |
| Transfer-Encoding | 指定报文主题的传输编码方式 |
| Upgrade | 升级为其他协议 |
| Via | 代理服务器相关的信息 |
| Warning | 错误通知 |
2 请求首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept | 用户代理可处理的媒体类型 |
| Accept-Charset | 优先的字符集 |
| Accept-Encoding | 优先的内容编码 |
| Accept-Language | 优先的语言（自然语言） |
| Authorization | Web认证信息 |
| Expect | 期待服务器的特定行为 |
| From | 用户的电子邮箱地址 |
| Host | 请求资源所在服务器 |
| If-Match | 比较实体标记（ETag） |
| If-Modified-Since | 比较资源的更新时间 |
| If-None-Match | 比较实体标记（与 If-Match 相反） |
| If-Range | 资源未更新时发送实体 Byte 的范围请求 |
| If-Unmodified-Since | 比较资源的更新时间（与If-Modified-Since相反） |
| Max-Forwards | 最大传输逐跳数 |
| Proxy-Authorization | 代理服务器要求客户端的认证信息 |
| Range | 实体的字节范围请求 |
| Referer | 对请求中 URI 的原始获取方 |
| TE | 传输编码的优先级 |
| User-Agent | HTTP 客户端程序的信息 |
3 响应首部字段
| 首部字段名 | 说明 |
|---|---|
| Accept-Ranges | 是否接受字节范围请求 |
| Age | 资源创建经过时间 |
| ETag | 资源的匹配信息 |
| Location | 令客户端重定向至指定URI |
| Proxy-Authenticate | 代理服务器对客户端的认证信息 |
| Retry-After | 对再次发起请求的时机要求 |
| Server HTTP | 服务器的安装信息 |
| Vary | 代理服务器缓存的管理信息 |
| WWW-Authenticate | 服务器对客户端的认证信息 |
4 实体首部字段
| 首部字段名 | 说明 |
|---|---|
| Allow | 资源可支持的HTTP方法 |
| Content-Encoding | 实体主体适用的编码方式 |
| Content-Language | 实体主体的自然语言 |
| Content-Length | 实体主体的大小（单位：字节） |
| Content-Location | 替代对应资源的URI |
| Content-MD5 | 实体主体的报文摘要 |
| Content-Range | 实体主体的位置范围 |
| Content-Type | 实体主体的媒体类型 |
| Expires | 实体主体过期的日期时间 |
| Last-Modified | 资源的最后修改日期时间 |
还有Cookie、Set-Cookie、Content-Disposition等非首部字段
端到端首部：
逐跳首部： Connection、Keep-alive、Proxy-Auth[xx]、Trailer、TE、Transfer-Encoding、Upgrade
以上描述的均为HTTP/1.1的字段
注：
- Cache-Control中：当max-age与expires同时存在时：1.1会忽略expires，1.0相反，revalidate指令必须再次验证源服务器的有效资源，若无则504。no-transform缓存无法改变实体主体的媒体类型[防止代替压缩]
- Connection有两个作用：
当值为字段时，则转发时会删除该字段。
当值为close、keep-alive时会控制持久连接。 - Date格式：Tue, 03 Jul 2018 04:40:44 GMT
- Pragma：为了兼容HTTP/1.1以下的版本，唯一值为no-cache
即同时使用两个字段来确全部中间服务器不缓存资源
Cache-Control: no-cache
Pragma: no-cache - Warning 由 HTTP/1.0的响应头部Retry-After演变
格式： [警告码] [警告的主机：端口] "[警告内容]" ([日期]) - Accept：格式 type/subtype;q=(0-1) q为权重 默认为1.0
- Authorization和www-Authenticate、Proxy-Authorization和Proxy-Authenticate
分别为客-服的服务器端和代理服务器的认证信息，未认证成功返回401 - 请求中使用Expect，当服务端无法满足时 返回417
- Host是唯一一个必须包含在请求中的首部字段
理由：由于URL会在请求中用IP地址替代，那么对于一个IP下存有多个域名/虚拟主机来说，就必须需要一个HOST来指名到底请求哪个主机，可为空值。 - 对于请求中带If-Match时，如果服务端判断为真则接受请求，为假时返回412
对于请求中带If-Modified-since时，如果服务端判断为真则接受请求，为假时返回304 - If-Range和Range同时使用
If-Range的值可以为ETag或者时间，匹配后返回Range的内容及206，否则全部资源。 - ETag区分强弱，
强ETag无论实体发生什么变化 都会改变ETag
弱ETag只有资源发生根本改变才改变ETag，字段值最开始附加W/ - Retry-After配合503告知客户端多久后再来访问
- Vary指定的首部字段若与请求中的字段相同则返回，不同则重新请求。
- 当服务端接收到非Allow字段中的方法时，会返回405，并在Allow写明所有支持的方法返回
- Content-MD5 用于客户端确认信息是否完全传输。但无法判断是否信息被篡改
内容 -> md5 (128位二进制数) -> Base64 - 若服务器不想让缓存服务器进行缓存时：
Expires与Date值保持一致即可
Cookie
- Set-Cookie： 开始状态管理所使用的cookie信息 【响应首部字段】
1 NAME=VALUE 赋予Cookie名称和值
2 Expires=DATE 赋予有效期（默认为关闭浏览器之前）
3 path=PATH、domain=域名（指明cookie适用的目录和域名）
4 Secure： 仅在HTTPS下才会发送Cookie （默认为均支持）
5 HttpOnly：Cookie不能被JS访问 - Cookie：服务器接收到的Cookie信息 【请求首部字段】
其他首部字段：
X-Frame-Options：控制Frame标签的显示问题，DENY/SAMEORIGIN
X-XSS-Protection：控制XSS防护机制开关，0/1 【1为开启】
DNT：控制个人信息是否被收集 0/1 【1为拒绝追踪】
P3P：使个人隐私变成仅供程序理解的形式
注：X- 语法被废除， 除DNT之外，其余都是响应首部
安全的HTTPS
明文传输易被窃听：
1 采用SSL、TSL进行传输
2 报文加密 ：仍然存在被篡改的危险不验证身份易伪装
1 SSL的证书验证
注：客户端和服务端都有可能是其他的，易遭到DOS（拒绝服务）攻击无法证明报文完整性，易被篡改
1 使用SSL提供的认证和加密处理及摘要功能
注：易遭到MITM（中间人）攻击
HTTPS：HTTP+加密+认证+完整性保护
对称密钥加密：仍能窃取到密钥，导致加密失效
非对称密钥：公钥和私钥，使用公钥加密，私钥解密。
数字签名是用私钥加密，当能用公钥解密时，即可确认发送方身份
服务端发送公钥给客户端，客户端生成随机数用公钥加密发送，
服务端用私钥解密客户端随机数，随后通信使用随机数加密。
即：先使用非对称密钥加密进行握手约定对称密钥，随后使用对称密钥进行通信。
WebSocket
WebSocket协议建立在HTTP基础上，所以需要在HTTP连接建立后进行一次'握手'。
首部字段：
Upgrade： WebSocket，通知服务器协议更换
Sec-WebSocket-Key：记录握手必不可少的键值
Sec-WebSocket-Protocol：记录使用的自协议
Sec-WebSocket-Accept：由Key值生成Accept的值
相关内容：XSS、CSRF、SQL注入、首部注入、OS注入等攻击
