网络请求

6 阅读8分钟

TCP协议

TCP概述

传输控制协议(TCP,Transmission Control Protocol) 是一种面向连接的、可拷的、基于字节流的传输层通讯协议

核心特性

  • 面向连接:通讯前必须建立连接
  • 可靠传输:确保数据完整、有序到达
  • 双全工通讯:支持双向同时传输
  • 流量控制:防止发送方过快淹没接收方
  • 拥塞控制:避免网络过载

TCP在协议栈中的位置

应用层    →  HTTP, FTP, SMTP等
传输层    →  TCP, UDP
网络层    →  IP
链路层    →  Ethernet, WiFi等

TCP报文格式

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         源端口号              |          目的端口号           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       序列号(SEQ)                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     确认号(ACK)                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 数据偏移 | 保留  |标志位|           窗口大小                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    校验和                    |     紧急指针                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    选项(可选)                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            数据                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

字段说明
字段           长度             说明
源端口号       16位             发送方端口
目的端口号     16位             接收方端口
序列号(SEQ)    32位             数据字节流的编号
确认号(ACK)    32位             期望收到的下一个序号
数据偏移       4位              TCP首部长度
保留           6位              保留将来使用
标志位         6位              URG、ACK、PSH、RST、SYN、FIN
窗口大小       16位             接收窗口大小
校验和         16位             校验首部和数据
紧急指针       16位             紧急数据的末尾位置 

标志位详解

  • URG:紧急指针有效
  • ACK:确认号有效
  • PSH:接收方应尽快将数据交给应用层
  • RST:重置连接
  • SYN:同步序号,用于建立连接
  • FIN:发送方完成数据发送

TCP连接管理

三次握手

目的是确认双方的收发能力都是正常的

  客户端                     服务器
 |                         |
 |----SYN, SEQ=x---------->|  (1) 客户端发送SYN
 |                         |
 |<---SYN, ACK, SEQ=y, ACK=x+1--|  (2) 服务器回应SYN+ACK
 |                         |
 |----ACK, SEQ=x+1, ACK=y+1--->|  (3) 客户端发送ACK
 |                         |
 |<===== 连接建立成功 =====>|

握手过程:

  1. 第一次握手:客户端发送SYN包(SEQ=x),进入SYN_SENT状态;表示:我想和你建立连接,此时客户端止到:我发信号的能力是没有问题的
  2. 第二次握手:服务器收到SYN包,回复SYN+ACK包(SEQ=y, ACK=x+1),进入SYN_RCVD状态;表示:收到请求了,我也准备好了,你确认一下?;此时服务端止到:您发信号正常,我接收信号和发信号也正常
  3. 第三次握手:客户端收到SYN+ACK包,回复ACK包(ACK=y+1),进入ESTABLISHED状态;服务器收到ACK后也进入ESTABLISHED状态;表示:收到,那我们开始聊吧;此时客户端止到:我接收信号也正常

为什么需要三次握手?

  • 防止已失效的连接请求突然传到服务器
  • 确保双方都有发送和接收能力
  • 同步双方的初始序列号

四次挥手(释放连接)

由于TCP是双开工的(双方都可以同时发送数据),所以关闭连接时,双方都需要单独确认自己不再发送数据了

客户端                     服务器
  |                         |
  |----FIN, SEQ=u---------->|  (1) 客户端发送FIN
  |                         |
  |<---ACK, SEQ=v, ACK=u+1---|  (2) 服务器回复ACK
  |                         |
  |<---FIN, SEQ=w, ACK=u+1---|  (3) 服务器发送FIN
  |                         |
  |----ACK, SEQ=u+1, ACK=w+1--->|  (4) 客户端发送ACK
  |                         |
  |     连接关闭             |

挥手过程:

  1. 第一次挥手:客户端发送FIN包(SEQ=u),进入FIN_WAIT_1状态;表述:告诉服务端“我的数据发完了,我要关闭发送通道了”
  2. 第二次挥手:服务器收到FIN,回复ACK包(ACK=u+1),进入CLOSE_WAIT状态;客户端收到ACK后进入FIN_WAIT_2状态;表示:知道了,但我还有点数据还没发完,你等我一下;此时客户端进入半开工状态,只收不发
  3. 第三次挥手:服务器发送FIN包(SEQ=w),进入LAST_ACK状态;表示:我也发完了,咱们散伙吧
  4. 第四次挥手:客户端收到FIN,回复ACK包(ACK=w+1),进入TIME_WAIT状态;服务器收到ACK后关闭连接;表示:行,拜拜;注意:客户端发完这个包后会等待2MSL(最大报文生存时间)才会正式关闭。这是为了防止最后的ACK丢了,导致服务端没法正常关闭

为什么需要TIME_WAIT状态?

  • 确保最后一个ACK能到达服务器
  • 防止旧连接的报文影响新连接
  • 通常持续2MSL(最大报文生存时间)

超时重传

流量控制

拥塞控制

HTTP协议

版本演进

  • HTTP/0.9 只有 GET 方法,仅传输 HTML,无头部。过于简陋
  • HTTP/1.0 引入版本号、状态码、头部概念,支持多种文件类型。每个 TCP 连接只能发送一个请求,效率低。
  • HTTP/1.1 主流版本引入持久连接 (Keep-Alive)、管道化 (Pipelining)、分块传输编码、更多的缓存控制。队头阻塞 (HOL blocking) 问题未完全解决。
  • HTTP/2.0 二进制分帧、多路复用 (Multiplexing)、头部压缩 (HPACK)、服务器推送 (Server Push)。基于 TCP,TCP 的队头阻塞问题依然存在。
  • HTTP/3.0 基于 QUIC 协议 (Quick UDP Internet Connections),使用 UDP 而非 TCP。解决 TCP 队头阻塞问题,连接建立更快。

主要方法

GET        请求指定的资源。用于获取数据,不应产生副作用。
HEAD       类似于 GET,但服务器只返回响应头,不返回响应体。用于检查资源是否存在或获取元信息。
POST       将数据提交给指定的资源,通常用于创建新资源或提交表单。
PUT        将数据发送到服务器以创建或替换指定的资源。通常用于更新整个资源。
DELETE     请求服务器删除指定的资源。
PATCH      对资源进行部分修改。
OPTIONS    描述目标资源的通信选项,允许客户端查看服务器支持的 HTTP 方法。

常见状态码

200  OK                                  成功
201  Created                             请求成功并创建了新资源。
301  Moved Permanently                   请求的资源已被永久移动到新 URL。将来应使用新 URL 访问。
302  Found                               请求的资源临时从不同的 URL 响应。客户端应继续使用原 URL。
304  Not Modified                        资源未修改,客户端可以使用缓存的版本。
400  Bad Request                         服务器无法理解请求的格式(参数错误、语义错误等)。
401  Unauthorized                        请求需要用户身份验证。
403  Forbidden                           服务器理解请求,但拒绝执行。权限不足。
404  Not Found                           服务器找不到请求的资源。
405  Method Not Allowed                  请求方法对指定的资源不适用。
500  Internal Server Error               服务器内部错误,服务器遇到意外情况,无法完成请求。
502  Bad Gateway                         错误网关,作为网关或代理工作的服务器,从上游服务器收到无效响应。
503  Service Unavailable                 服务不可用,服务器当前无法处理请求(超载、停机维护)

常见请求/响应头

Host             请求头        指定请求资源的主机名和端口号。
User-Agent       请求头        客户端程序的信息(如浏览器类型)。
Accept           请求头        告诉服务器,客户端能接受哪些媒体类型。
Content-Type     请求/响应头   告诉对方,当前发送的数据是什么类型。
Content-Lenght   请求/响应头   请求体或响应体的数据长度。
Referer          请求头        表示当前请求是从哪个页面链接过来的。
Cookie           请求头        客户端将存储的 Cookie 发送给服务器。
Set-Cookie       响应头        服务器要求客户端保存 Cookie。
Location         响应头        通常与 3xx 状态码一起使用,告诉客户端要重定向到哪里。
Cache-Control    请求/响应头   指定缓存机制
Authorization    请求头        用于向服务器发送身份验证凭证

HTTPS协议

概述

HTTPS (Hypertext Transfer Protocol Secure)  是 HTTP 的安全版本,通过在 HTTP 和 TCP 之间加入 SSL/TLS 协议层来实现加密传输。

为什么需要 HTTPS?

HTTP 存在三大安全隐患:

  1. 窃听风险:通信使用明文,内容可以被第三方截获。
  2. 篡改风险:无法验证报文的完整性,内容可能被修改。
  3. 冒充风险:不验证通信方的身份,可能遭遇伪装服务器。

HTTPS 解决的问题

  • 机密性:加密数据,防止被窃听。
  • 完整性:防止数据被篡改。
  • 身份验证:验证网站的真实性,防止钓鱼网站。
    subgraph HTTP
        A[客户端] -->|明文传输| B[服务器]
    end

    subgraph HTTPS
        C[客户端] -->|SSL/TLS 加密| D{SSL/TLS层}
        D -->|解密| E[服务器]
    end

SSL/TLS 协议

什么是 SSL/TLS?

  • SSL:Secure Sockets Layer,安全套接层。
  • TLS:Transport Layer Security,传输层安全协议(SSL 的继任者)。

核心功能

功能描述解决的安全问题
加密对传输的数据进行加密,即使被截获也无法读取。窃听风险
认证通过数字证书验证通信方的身份。冒充风险
完整性校验通过消息认证码(MAC)确保数据未被篡改。篡改风险

工作原理

HTTPS 握手过程主要分为三个阶段:

  1. TCP 连接建立:三次握手。
  2. TLS 握手:协商加密算法、验证证书、生成会话密钥。
  3. 加密通信:使用会话密钥进行对称加密通信。

OKHttp介绍

RxJava介绍

Retrofit介绍

Retrofit+RxJava+OkHttp Android项目