HTTP 和 HTTPS

OSI 七层模型

OSI（Open System Interconnection），由底层到高层分别为：

• 物理层
• 数据链路层
• 网络层
• 传输层：TCP/UDP
• 会话层
• 表示层
• 应用层：HTTP

TCP/UDP

TCP

TCP 中连接的建立需要三次握手，在通信结束时断开连接需要四次挥手。一个连接的建立与断开，正常过程至少需要来回送 7 个包才能完成。

建立 TCP 连接时的三次握手：

1. 客户端向服务器发送一个 SYN（synchronous）,客户端进入 SYN_SEND 状态
2. 服务器收到 SYN 包后，服务器进入 SYN_RECV 状态，发出 SYN+ACK（Acknowledgement）
3. 客户端收到 SYN+ACK 后发出 ACK 确认给服务器,客户端进入 ESTABLISH 状态。
4. 服务器收到 ACK 后，服务器进入 ESTABLISH 状态。

建立连接后，传输数据。

断开 TCP 连接时的四次挥手：

1. 客户端发送发送一个 FIN，等待服务器返回 ACK 和 FIN，客户端进入 FIN_WAIT_1 状态；
2. 服务器接收 FIN，发出一个收到 FIN 的 ACK 确认，服务器进入 Close Wait 状态；
3. 客户端收到 ACK，继续等待服务器的 FIN，客户端进入 FIN_WAIT_2 状态；
4. 服务器发送 FIN，服务器等待客户端收到 FIN 的 ACK，服务器进入 LAST_ACK 状态；
5. 客户端收到 FIN，发出 ACK，客户端进入 TIME_WAIT 状态（2MSL等待状态）；等到 2MSL 后，客户端进入 CLOSE 状态
6. 服务器接收 ACK，服务器进入 CLOSE 状态；

连接断开。

UDP

UDP 不提供复杂的控制机制，利用 IP 提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻，立即按照原样发送到网络上的一种机制。

特点：

• 无需建立连接（减少延迟）
• 实现简单：无需维护连接状态
• 头部开销小
• 没有拥塞控制：应用可以更好的控制发送时间和发送速率

TCP 与 UDP 的区别

1. TCP 面向连接；UDP 是无连接的，即发送数据之前不需要建立连接；
2. TCP 提供可靠的服务。即通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP 尽最大努力交付，即不保证可靠交付
3. TCP 面向字节流，实际上是 TCP 把数据看成一连串无结构的字节流；UDP 是面向报文的，没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）
4. 每一条 TCP 连接只能是点到点的；UDP 支持一对一，一对多，多对一和多对多的交互通信
5. TCP首部开销 20 字节；UDP 的首部开销小，只有 8 个字节

Socket

Socket 是对 TCP/IP 协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过 Socket，我们才能使用 TCP/IP 协议。

在 socket 编程中，客户端执行 connect() 时,将触发三次握手。在 socket 编程中，任何一方执行 close() 操作即可产生挥手操作。

Socket 连接与 HTTP 连接的不同。通常情况下 Socket 连接是 TCP 连接，因此 Socket 连接一旦建立，通信双方即可开始相互发送数据内容，直到双方连接断开。但实际应用中，客户端到服务器之间的通信防火墙默认会关闭长时间处于非活跃状态的连接而导致 Socket 连接断开，因此需要通过轮询告诉网络，该连接处于活跃状态。

而 HTTP 连接使用的是“请求—响应”的方式，不仅在请求时需要先建立连接，而且需要客户端向服务器发出请求后，服务器端才能回复数据。

长连接

在 TCP 连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接，一般需要自己做在线维持。

• 连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。

每个 TCP 连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完成后都不断开，下次处理时直接发送数据包就可以了，不用建立 TCP 连接。

短连接

指通信双方有数据交互时，就建立一个TCP连接，数据发送完成后，则断开此TCP连接

• 连接→数据传输→关闭连接；

HTTP

一次完整的 HTTP 请求过程：

• 从 TCP 三次握手建立连接成功后开始
• 客户端按指定格式向服务端发送 HTTP 请求
• 服务端接受请求后，解析 HTTP 请求，处理完业务逻辑，返回一个 HTTP 响应给客户端
• HTTP 的响应内容有标准的格式

HTTP 请求报文

一个 HTTP 请求报文组成部分有：

• 请求行：请求方法（GET/POST/DELETE/PUT/HEAD）、URL 路径、HTTP 的版本号
• 请求头部：缓存、客户端信息等
• 空行
• 请求数据

请求方法：

• HTTP 1.0 定义的方法：
  • GET：请求指定的页面信息，并返回实体主体。
  • HEAD：类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头。
  • POST：向指定资源提交数据进行处理请求（修改）。数据被包含在请求体中
• HTTP 1.1 新增的方法：
  • PUT：从客户端向服务器传送的数据取代指定的文档的内容。
  • Delete：请求服务器删除指定的页面。
  • TRACE：回显服务器收到的请求，主要用于测试或诊断。
  • CONNECT：预留给能够将连接改为管道方式的代理服务器。
  • OPTIONS：允许客户端查看服务器的性能。

HTTP 返回报文

一个 HTTP 返回报文组成部分有：

• 状态行：有 HTTP 协议版本号，状态码和状态说明
• 响应头部
• 空行
• 响应包体

状态码：

• 200：请求成功
• 301：被请求的资源已永久移动到新位置。服务器返回此响应（GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
• 404：没有找到
• 405：方法不允许
• 408：请求超时
• 500：服务器内部错误

HTTP 长连接

HTTP1.1 开始，默认 TCP 保持长连接，即任意一端没有提出断开连接，则会一直保持连接状态。一次长连接可进行多次请求和响应，这样可以减少建议连接和断开连接的开销，减少服务器负载，加快 HTTP 请求和响应。

Cookies

HTTP 是无状态协议，但有时客户端与服务端需要保持某些状态，于是引入 Cookie 技术。Cookie 是通过在请求和响应报文中写入 Cookie 信息来控制客户端状态。

Cookie 根据从服务端发送的响应报文中的一个 Set-Cookie 头部信息，通知客户端来保持 Cookie。当下次客户端再往服务器发送请求时，客户端会自动在请求报文中加入 Cookie 后发送出去。

服务端发现客户端发送来的 Cookie 后，会去检查这是从哪个客户端发来的连接请求，对比服务器记录，得到状态信息。

Session

在服务端保持状态的方案。

HTTPS

HTTPS 从最终的数据解析角度，与 HTTP 没有任何的区别。HTTPS 是将 HTTP 协议数据包放到 SSL/TSL层（应用层）加密后，在 TCP/IP 层组成 IP 数据包去传输，以保证传输数据的安全。

对于接收端，在 SSL/TSL 将接收的数据包解密后，将数据传给 HTTP 协议层，就变成了普通的 HTTP 数据。其中 HTTP 和 SSL/TSL 都处于 OSI 模型的应用层。

HTTP 的不足

• 通信使用明文，内容容易被窃听
• 不验证通信双方的身份，有可能遭遇伪装
• 无法证明报文的完整性，有可能遭到篡改

对称加密和非对称加密

对称加密：在加密和解密时使用同一个秘钥。

非对称加密：需要一对公钥和私钥，如果通过公钥对数据进行加密，只能通过对应的私钥解密；如果通过私钥对数据进行加密，则只能通过对应的公钥来解密。

SSL/TSL

主要交换三个信息：

数字证书

该证书包含了公钥等信息，一般由服务器发送给客户端，接收方通过验证这个证书是不是有信赖的 CA 签发，或与本地的证书相对比来判断证书是否可信。如需要双向验证，则服务器和客户端都需要发送数字证书给对方验证。

三个随机数

这三个随机数构成了后续通信过程中用来对数据进行对称加密解密的对话秘钥。

• 先从客户端发送第一个随机数 N1
• 之后服务器返回第二个 N2（同时发送证书给客户端），两个随机数都是明文的；
• 而第三个随机数 N3，是客户端通过数字证书的公钥进行非对称加密得到的，发送给服务端。
• 服务端通过自己的私钥解密得到 N3
• 这是服务端和客户端都有个三个随机数 N1+N2+N3，两端通过这三个随机数来生成对话秘钥，之后的通信使用这个对话密钥来进行对称加密解密
• 过程中服务端的私钥始终在服务端，没有经历过网络传输，这样私钥不会被泄露，保证了数据的安全

完整过程如下图：

加密通信协议

客户端和服务端商量使用哪一种加密方式，若两者支持的加密方式不匹配，则无法进行通信。

为什么随机数要有三个？

由于 SSL/TSL 的设计，假设某个客户端提供的随机数不随机，会大大增加对话密钥被破解的风险，而通过 3 个随机数得到的对话密钥，很大程度上保证了随机数的随机性，以此来保证生成的对话密钥的安全性。

HTTPS 抓包原理

1. 抓包程序将服务器返回的证书截获
2. 之后给客户端返回一个抓包程序的证书
3. 客户端发送的数据使用抓包程序给的证书生成的密钥加密
4. 抓包程序得到客户端发送的数据，抓包程序用自己的证书解密出来，再用服务器证书加密
5. 抓包程序再把数据发送给服务器

总结

• OSI 七层模型
• TCP 3 次握手（SYN + ACK）
• TCP 4 次挥手（FIN + ACK）
• UDP（一对多、不需要建立连接）
• Socket（对 TCP/IP 的封装、connect()、close()、轮询保持活跃）
• HTTP
  • TCP 握手建立连接
  • HTTP 请求
  • 返回 HTTP 响应
  • HTTP 请求报文
    • 请求行（请求方法、URL、HTTP 版本等）
    • 请求头（缓存、客户端信息等）
    • 空行
    • 请求体
  • 请求方法：
    • HTTP 1.0
      • GET
      • HEAD
      • POST
    • HTTP 1.1
      • PUT
      • DELETE
      • CONNECT
      • OPTIONS
  • HTTP 返回报文
    • 状态行（HTTP 版本、状态码、状态说明）
    • 响应头
    • 空行
    • 响应体
  • 状态码：
    • 200
    • 301 新位置
    • 404 没找到
    • 405 方法不允许
    • 408 请求超时
    • 500 服务器内部错误
  • cookie & session
    • HTTP 无状态
    • Set-Cookie 开启
    • 客户端发请求带 cookie
    • 服务器检查 cookie
• HTTPS
  • HTTP 不足
    • 明文，窃听
    • 不验证身份，伪装
    • 不保证报文完整，篡改
  • 原理
    • 通过 SSL/TSL（应用层）加密 HTTP 协议数据包
    • 再用 TCP/IP 组成 IP 数据包传输
    • 除了加密解密过程，其他和 HTTP 一样
  • SSL/TSL
    • 数字证书
    • 三个随机数 N1、N2（+公钥）、N3
    • 加密通信协议确定
• HTTPS 抓包原理
  • 抓包程序截获服务器证书
  • 给客户端自己的证书
  • 客户端按该证书公钥加密
  • 抓包软件收到客户端加密数据，自己解密
  • 再用服务器证书加密
  • 发给服务器

许可协议

本文采用 署名-非商业性使用-相同方式共享 4.0 国际 许可协议，转载请注明出处。

分享文章