TCP/IP 、HTTPIP：IPV4 共有32位组成，IPV6共有128位组成。 IP地址分为五大类：A、B、C、D、

1，协议栈分层

应用层: HTTP、FTP、DNS
传输层: TCP、UDP
网络层: IP
链路层: OS、Driver、网卡
硬件层:

2，传输流程

发送：

应用层->	传输层->	网络层->	链路层
HTTP报文	TCP首部+HTTP报文	IP首部+TCP首部+HTTP报文	以太网首部+IP首部+TCP首部+HTTP报文

接收：

链路层->	网络层->	传输层->	应用层
以太网首部+IP首部+TCP首部+HTTP报文	IP首部+TCP首部+HTTP报文	TCP首部+HTTP报文	HTTP报文

3，详解

IP：IPV4 共有32位组成，IPV6共有128位组成。

IP地址分为五大类：A、B、C、D、E。

A: 0 + 7位网络号 + 24位主机号 (1~126)

B: 10 + 14位网络号 + 16位主机号(128~191)

C: 110 + 21位网络号 + 8位主机号(192~223)

D: 1110 + 28位多播组号(224~239)

E:11110 + 27位（保留）(240~255)

详细了解子网掩码和子网划分请移步51CTO子网划分
HTTP: 无状态的协议，HTTP/1.1默认是持久连接
URI：资源标识符、URL:资源定位符
请求方法：
- GET: 获取URI资源，地址参数不安全
- POST: 传输实体主体，POST主要不是获取资源
- PUT：传输文件，报文主体直接保存在服务器的指定的URI上
- DELETE: 删除文件，删除服务器上的指定URI的资源
- HEAD: 获取报文首部，而不是报文主体
- OPTIONS: 查询请求URI资源支持的方法
- TRACE: 让服务器将之前的请求通信还回给客户端。容易引发跨站追踪
- CONNECT:要求用隧道协议链接代理
cookie：为了保持状态引入cookie技术。客户端保存cookie(sid)。

客户端请求->服务端生成cookie保存并发送给客户端

客户端请求附带cookie->服务端检查cookie然后响应
HTTP报文
- 请求报文和响应报文（CR+LF)做换行符
- 结构如下：

GET /HTTP/1.1             // 请求行
-------------------------------------------
Host:baidu.com
User-Agent:Mozilla/5.0 
Accept:text/html
Connection:no-cache
Cache-Control:no-cache    //各首部字段
-------------------------------------------
空行（CR+LF)
-------------------------------------------

HTTP/1.1 200 OK           // 状态行
-------------------------------------------
Date:Fri.13 Jul 2018 GMT
Server:ngix
Last_Modified:Fri .31 Aug 2017 GMT
ETag:"3627adasd-dasdasd9-da3e33"
Content-Length:362
Connection:close
COntent-Type:text/html     // 各首部字段
-------------------------------------------
<html>
    <head>
    </head>
    <body>
    </body>
</html>                    //报文主体
---------------------------------------------

HTTP报文主体和报文实体的差异
- 报文（message）:是HTTP通信中的基本单元，8位组字节流组成
- 实体（entity）: 是有效载荷的数据。实体首部和实体主体组成
压缩：
- gzip: GNU zip
- compress: UNIX系统标准压缩
- deflate: zlib
- identity: 不编码
传输编码格式：multipart/form-data
断点续传/范围请求（Rang/ETag）
状态码：
- 1xx:Informational信息状态码
- 2xx:Success成功状态码
- 3xx:Redirection重定向状态码
- 4xx:Client Error客户端错误状态
- 5xx:Server Error服务端错误状态
代理、网关、隧道

1，代理：
- 接受客户端请求转发给服务器
- 代理不改变请求的URI
- 缓存代理
- 透明代理和非透明代理（是否对报文进行处理）
2，网关：
- 能使通信服务器提供非HTTP协议服务
- 客户端HTTP->网关->非HTTP服务器
3，隧道：
- 按要求建立一条与其他服务器的通信线路，使用SSL加密手段进行通信
- 隧道本身不会解析HTTP请求
头部缓存Cache-Control
- 1，请求指令
- no-cache：强制向源服务器再次验证
- no-store: 不缓存请求或者响应的任何内容
- max-age：响应的最大age值
- only-if-cached :从缓存获取资源
- cache-extension：新指令标记（token)
- 2，响应指令
- public:可向任意方提供响应的缓存
- private:可省略，仅向特定的用户返回响应
- no-cache：缓存请必须验证有效性
- no-store：不缓存请求或者相应的任何内容
- no-transform：代理不可更改媒体类型
- must-revalidate:可缓存但必须向服务器确认
- proxy-revalidate:要求中间服务器对缓存的响应进行确认
- max-age：响应的最大age值
- cache-extension：新指令标记（token)
头部其他字段
- connection:管理持久连接
- Date：报文创建的日期
- Pragma:HTTP/1.0遗留字段
- Trailer:事先说明报文主体后面记录了那些首部字段，可以在HTTP/1.1应用分块传输
- Tranfer-Encodeing：报文主体的编码方式。HTTP/1.1仅对分块传输有效
- Upgrade:监测HTTP协议是否有其他更高版本
- Via：为了追踪客户端和服务端之间的请求和响应报文
- Warning：缓存的相关警告-- Response is stale (代理返回过期的资源)，Revalidation failed（再次验证资源时失败）
- Authorization：用户代理的认证信息
- Host:告诉服务器请求资源所处的主机名和端口号
- cookie-Set-Cookie:认证信息
  
  4，HTTPS
HTTP缺点
- 通信使用明文，内容可能被窃听
- 不验证通信方的身份，有可能遭到伪装
- 无法验证明文的完整性，有可能篡改
SSL通信流程
- 1，客户端向服务器请求（ClientHello）
- 2，服务器给客户端一个公钥证书（ServerHello） ------ 第一次握手结束Hello
- 3，客户端用公钥证书向数字证书认证机构检验(校验)
- 4，客户端认证通过，说明公钥可靠。客户端随机生成对称秘钥，用公钥加密对称秘钥发给服务器端
- 5，服务端用私钥解密获取对称秘钥 -------第二次握手结束ChangeCipherSpec
- 6，以后通信就用对称秘钥加密了
  - 备注1
    
    步骤4中对称秘钥并不是最终的Master_key，可以暂且认为一个随机数PreMaster-Key
    
    它最终会计算生成对称秘钥
    
    步骤1，2，主要是握手Hello，协商加密组件
    
    步骤4开始，客户端会传递ChangeCipherSpec，告诉服务端以后要改变密码规则,以后将采用PreMaster_Key秘钥加密
  - 备注2:
    
    在步骤1中，ClientHello传递给Server的信息有SSL版本信息+随机数1
    
    在步骤2中，ServerHello传递给Client的信息有CA证书 + 随机数2
    
    步骤3中是客户端向数字认证机构进行认证，比如VeriSign机构
    
    步骤4中，认证完成。客户端传递给Server的信息随机数3，这个随机数3就是PreMaster-Key
    
    步骤5中，Server获取PreMaster-Key，计算生成Master-Key，同时客户端也计算生成Master-Key
  - 在备注1中，由于握手过程是明文的。随机数1和随机数2任何人都可以获得。所以随机数3至关重要。理论上如果随机数3长度超过2048。破解难度是很大的。但是需要传递PreMaster-Key。
    
    如果采用Diffie-Hellman算法，PreMaster_Key不需要传递，双方交换参数，就可以算出PreMaster_Key
    
    Diffie-Hellman算法原理：
    
    已知：随机大素数p, 以及其本原根g：g一般来说可以去2或者5
    
    Client的随机数A, Server的随机数B:
    
    $g^A\quad mod\quad p =\ R_A \quad \quad 发送给Server结果R_A\\ g^B\quad mod\quad p = \ R_B \quad \quad发送给Client结果R_B\\ 则：(R_B)^A\quad mod\quad p =\ (R_A)^B\quad mod\quad p \\ 最终PreMasetr-Key = (R_B)^A\quad mod\quad p$
    
    由上可知：Client已知参数：g、p、A、RB；
    
    Server已知参数：g、p、B、RA；
    
    最终都能计算出PreMaster-Key：（RB）^A mod p
    
    Diffie-Hellman算法的风险：
    
    可能会被中间人攻击
所以最终的HTTPS就成下图：参考阮一峰的网络日志

SPDY
- SPDY的出现是为了解决服务端有更新，而客户端不能及时收到的瓶颈
- SPDY没有完全改写HTTP,而是在TCP/IP和应用层之间新加会话层
- 多路复用流单一的TCP连接，可以无限制处理多个HTTP请求，
- 可以赋予请求优先级
- 压缩HTTP首部，主动推送功能
- 缺点：对多个域名下的资源会受到限制

5，WebSocket

建立在HTTP基础上的协议
一次握手
增加Upgrade字段

6，总结

以上为读《图解HTTP》的笔记，虽然这本书读了好多次了，但是每次读都有新感觉。
笔记为证

TCP/IP 、HTTP

1，协议栈分层

2，传输流程

3，详解

4，HTTPS

5，WebSocket

6，总结