HTTP | Code Prose

type

status

date

slug

summary

URL 和 HTTP 报⽂

URL 格式

三部分：协议类型、服务器地址(和端⼝号)、路径(Path) 协议类型://服务器地址[:端⼝号]路径 http://hencoder.com/users?gender=male

报⽂格式

请求报文

响应报文

请求方法

获取资源，标准的 GET 方法的请求报文中是没有 Body 的。

报文：

Retrofit 代码：

POST

增加或修改资源，请求报文中有 Body

报文：

Retrofit 代码：

修改资源，请求报文中有 Body

报文：

Retrofit代码：

DELETE

删除资源，请求报文中没有 Body

报文：

Retrofit代码：

HEAD

和GET的请求一样，但是响应报文中没有 Body

状态码

作用：对结果做出类型话描述（如【获取成功】【内容未找到】）

1xx：临时性消息,如：100 （继续发送）、101（正在切换协议）

2xx：成功,最典型的是 200（OK）、201（创建成功）

3xx：重定向,如 301（永久移动）、302（暂时移动）、304（内容未改变）

4xx：客户端错误,如 400（客户端请求错误）、401（认证失败）、403（被禁⽌）、404（找不到内容）。

5xx：服务器错误,如 500（服务器内部错误）。

Header 和 Body

作用：HTTP 消息的元数据（metadata）

💡

元数据，首先要弄明白什么是“元”，“元”是一个抽象的概念，表示什么的什么。比如有一个经典的故事：从前有座上，山上有个庙，庙里有个老和尚在给一个小和尚讲故事，讲的是，从前有座山……，这里老和尚讲的故事就是这个故事的故事，那么故事里面故事就是外面的故事的元故事。再比如：父亲给女儿讲故事，故事是爱丽丝梦游仙境，那么爱丽丝梦游仙境就是父亲讲的故事的元故事。弄懂了这些，元数据就是数据的数据。

由于 Http 中主要关注的数据是 Body，而 Body 的大小，格式等信息就被称为元数据。

Host：⽬标主机。注意：不是在⽹络上⽤于寻址的，⽽是在⽬标服务器上⽤于定位⼦服务器的。

目标主机如果是域名的话，在浏览器发送 HTTP 请求之前，还需要通过 Dns 解析出域名所对应的 IP，才能定位主机。另外同一个主机上可能有多个不同域名的服务，Host 就能够帮助区分改请求交给哪个服务进行处理。

Content-Length：内容的长度（字节）

Content-Type：内容的类型

text/html: html 文本，用于浏览器页面响应

application/x-www-form-urlencoded：普通表单（纯文字），encoded URL 格式

前端请求代码：

报文格式是：

如果使用 Retrofit：

multipart/form-data: Web ⻚⾯含有⼆进制⽂件时的提交⽅式。

前端请求代码：

报文格式：

Retrofit 代码：

application/json:json 形式，用于 Web Api 的响应或 Post/PUT 请求

请求报文：

Retrofit 代码

image/jpeg、application/zip …: 单文件，用于 Web Api 响应或 POST/PUT

请求报文（上传图片）

Retrofit代码：

Transfer-Encoding: chunked (分块传输编码 Chunked Transfer Encoding)

表示Body长度无法确定，Content-Length不能使用

Body格式：

实际报文案例：

目的：在服务器还未获取到完整内容是，更快对客户端做出响应，减少用户等待。

Location:指定重定向的⽬标 URL（重定向会多请求一次，但是浏览器和 OkHttp 会等所有请求结束再回调，看上去只请求了一次，实际上不是）

User-Agent：⽤户代理，即是谁实际发送请求、接受响应的，例如⼿机浏览器、某款⼿机App。

Range / Accept-Range：按范围取数据

作⽤：断点续传、多线程下载。 Accept-Range: bytes 响应报⽂中出现，表示服务器⽀持按字节来取范围数据 Range: bytes=<start>-<end> 请求报⽂中出现，表示要取哪段数据 Content-Range:<start>-<end>/total 响应报⽂中出现，表示发送的是哪段数据

Accept: 客户端能接受的数据类型。如 text/html

Accept-Charset: 客户端接受的字符集。如 utf-8

Accept-Encoding: 客户端接受的压缩编码类型。如 gzip

Content-Encoding：压缩类型。如 gzip

Cache

作⽤：在客户端或中间⽹络节点缓存数据，降低从服务器取数据的频率，以提⾼⽹络性能。

Cache 和 Buffer 的区别：

Cache：缓存，用完了不丢，下次有重复请求，直接用存着的数据返回给他。

Buffer：缓冲，针对工作流，上游生产太快，暂时存着。或者下游消费太快了，提前生产存着。

REST

另一说：表征状态转移
“ REST（REpresentational State Transfer，表征状态转移）”
“HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机制，所以直接使用这两个方法，就存在安全问题。当配合 Web 应用程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的”。PUT/DELETE 在 HTTP 协议中是否安全主要跟代码逻辑相关，并非是使用了这种方法就造成访问不安全，由于代码是运行在容器中，如果容器配置不当，会导致一些安全风险，安全工程师并不理解代码背后的逻辑，从而将 PUT、DELETE 给一刀切了。

什么是REST：A software architectural style that defines a set of constraints to be used for creating Web service.(一种施加在Web服务的软件架构风格)

Client-server architecture （CS架构）

Statelessness（无状态）

Cache ability (可缓存)

Layered system （分层系统）

Code on demand （服务器返回的数据中可以包含可执行的代码，可选）

Uniform interface （统一接口）

Resource identification in requests （通过请求就足够确认资源的身份）
Resource manipulation through representations （客户端通过表示操作服务器资源）
Self-descriptive messages （字描述，请求和响应中包含字描述信息）
Hypermedia as the engine of application state(HATEOAS) (需要有一个顶级的超链接提供服务端所有可以查看的资源，类似于网站首页)

以上所有风格，HTTP 默认都已经支持，或已经是 HTTP 的特性，但是大部分开发者都没有遵守上述要求使用，导致大家都在强调，使用 REST 风格。

REST 的定义众说纷纭，没有统⼀答案。扔物线的观点：REST HTTP 即正确使⽤ HTTP。包括：

使⽤资源的格式来定义 URL

规范地使⽤ method 来定义⽹络请求操作

规范地使⽤ status code 来表示响应状态

其他符合 HTTP 规范的设计准则

💡

首先要明确一点：REST 实际上只是一种设计风格，它并不是标准。（所以你可以看到网上一大堆的各种最佳实践，设计指南，但是没有人说设计标准）。

1、REST 是面向资源的，这个概念非常重要，而资源是通过 URI 进行暴露。

URI 的设计只要负责把资源通过合理方式暴露出来就可以了。对资源的操作与它无关，操作是通过 HTTP 动词来体现，所以 REST 通过 URI 暴露资源时，会强调不要在 URI 中出现动词。

基于 HTTP 的协议

Ajax

Ajax（Asynchronous JavaScrip and XML，异步JavaScript与XML技术）是一种有效利用 javaScript 和 DOM 的操作，以达到局部 Web 页面替换加载的异步通信手段。由于他只更新一部分页面，响应中传输的数据量会因此减少

Ajax 的核心技术名为 XMLHttpRequest 的 API，通过 JavaScript 脚本语言就能和服务器进行 HTTP 通信，借由这种手段，就能从已经加载完毕的页面发起请求，从而更新局部页面。

WebSocket

WebSocket，即 Web 浏览器与 Web 服务器之间全双工通信标准，主要是为了解决 Ajax 和Comet 里 XMLHttpRequest 附带的缺陷引起的问题。

一但建立起 WebSocket 通信，之后所有的通信都可以通过这个专用协议进行。通信过程中可以互相发送 JSON，XML，HTML 或图片等任意格式的数据。

原理

1. 握手阶段

WebSocket 通信始于一个 HTTP 握手请求：

客户端请求：客户端发送一个 HTTP 请求，包含 Upgrade: websocket 和 Connection: Upgrade 头部，请求将协议升级为 WebSocket。

服务器响应：服务器同意升级后，返回 HTTP 101 状态码（Switching Protocols），表示协议切换成功。

2. 数据帧传输

握手成功后，连接保持打开，双方通过数据帧进行通信：

数据帧结构：WebSocket 数据帧包含操作码、掩码、负载长度等信息，支持文本、二进制等多种数据类型。

双向通信：客户端和服务器可以随时发送数据，无需等待请求。

3. 保持连接

WebSocket 连接持久化，直到一方主动关闭或网络中断。通过心跳机制（Ping/Pong 帧）检测连接状态。

4. 关闭连接

任一方可发送关闭帧，另一方回应后，连接关闭。

优点

实时性：支持即时通信。

低开销：相比 HTTP 轮询，减少了头部开销。

双向通信：客户端和服务器均可主动发送数据。

应用场景

实时聊天

在线游戏

实时数据推送

HTTP2.0

“HTTP/2.0 的目标是改善用户在使用 Web 时的速度体验。由于基本上都会先通过 HTTP/1.1 与 TCP 连接，现在我们以下面的这些协议为基础，探讨一下它们的实现方法。”

压缩	SPDY、Friendly
多路复用	SPDY
TLS 义务化	Speed＋ Mobility
协商	Speed＋ Mobility，Friendly
客户端拉曳（Client Pull）/服务器推送（Server Push）	Speed＋ Mobility
流量控制	SPDY
WebSocket	Speed＋ Mobility