http协议学习总结

一、HTTP简介

HTTP协议，即超文本传输协议(Hypertext transfer protocol)。是一种详细规定了浏览器和万维网(WWW = World Wide Web)服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。

 

二、 HTTP协议的特点

1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
3、HTTP 0.9和1.0使用非持续连接：限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。HTTP 1.1使用持续连接：不必为每个web对象创建一个新的连接，一个连接可以传送多个对象，采用这种方式可以节省传输时间。
4、无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
5、支持B/S和C/S模式。

 

三、HTTP的工作流程

一次HTTP操作称为一个事务，其工作过程可分为四步：
1、首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。
2、建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
3、服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
4、客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。

四、URI和URL的区别

1、URI

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。
Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的。URI一般由三部组成：
(1)、访问资源的命名机制；
(2)、存放资源的主机名；
(3)、资源自身的名称，由路径表示，着重强调于资源。

2、URL

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何定位这个资源。
URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
(1)、协议(或称为服务方式)；
(2)、存有该资源的主机IP地址(有时也包括端口号)；
(3)、主机资源的具体地址。如目录和文件名等。
HTTP URL的格式如下所示：
http://host[＂:＂port][abs_path]
https://www.jianshu.com/u/72588c94a841
http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个 端口号，为空则使用默认端口80；abs_path指定请求资源的URI（Web上任意的可用资源）。

 

五、HTTP请求报文

HTTP 报文是面向文本的，报文中的每一个字段都是一些ASCII码串，各个字段的长度是不确定的。一 般一个HTTP请求报文由请求行、请求报头、空行和请求数据4个部分组成。如下图：

1.请求行

请求行由请求方法、URL字段和HTTP协议的版本组成，格式如下：
Method Request-URI HTTP-Version CRLF 其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议 版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

HTTP请求方法有8种，分别是GET、POST、HEAD、PUT、DELETE、TRACE、CONNECT、 OPTIONS。对于移动开发最常用的就是GET和POST了。
• GET：请求获取Request-URI所标识的资源。
• POST：在Request-URI所标识的资源后附加新的数据。
• HEAD：请求获取由Request-URI所标识的资源的响应消息报头。
• PUT：请求服务器存储一个资源，并用Request-URI作为其标识。
• DELETE：请求服务器删除Request-URI所标识的资源。
• TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断。
• CONNECT：HTTP 1.1协议中预留给能够将连接改为管道方式的代理服务器。
• OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项和需求。

 

2.请求报头

请求报头通知服务器关于客户端请求的信息。在下文HTTP的消息报头中详细介绍

 

3.请求数据

请求数据不在GET方法中使用，而在POST方法中使用。POST方法适用于需要客户填写表单的场合， 与请求数据相关的最常用的请求报头是Content-Type和Content-Length

4.示例

六、HTTP响应报文

在接收和解释请求消息后，服务器返回一个HTTP响应消息。HTTP 的响应报文由状态行、响应报头、空行、响应正文组成。

1.状态行

状态行格式如下所示：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态码；ReasonPhrase表示状态码的文本描述。状态码由3位数字组成，第一个数字定义了响应的类别，且有以下5种可能取值:
• 100～199：指示信息，收到请求，需要请求者继续执行操作。
• 200～299：请求成功，请求已被成功接收并处理。
• 300～399：重定向，要完成请求必须进行更进一步的操作。
• 400～499：客户端错误，请求有语法错误或请求无法实现。
• 500～599：服务器错误，服务器不能实现合法的请求。
常见的状态码如下：
• 200 OK：客户端请求成功。
• 301: 请求永久重定向
• 400 Bad Request：客户端请求有语法错误，服务器无法理解。
• 401 Unauthorized：请求未经授权，这个状态码必须和WWW-Authenticate报头域一起使用。
• 403 Forbidden：服务器收到请求，但是拒绝提供服务。
• 500 Internal Server Error：服务器内部错误，无法完成请求。
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常。

参考 ：https://tool.oschina.net/commons?type=5

 

2.响应报头

用于服务器传递自身信息的响应。在下文HTTP的消息报头中详细介绍

3.响应正文

响应正文就是服务器返回的资源的内容。

4.示例

七、HTTP的消息报头

消息报头分为通用报头、请求报头、响应报头、实体报头等。消息报头由键值对组成，每行一对，关键字和值用英文冒号“：”分隔。

 

1.通用报头

它既可以出现在请求报头，也可以出现在响应报头中，如下所示：
• Date：表示消息产生的日期和时间。
• Connection：允许发送指定连接的选项。例如指定连接是连续的；或者指定“close”选项，通知服务 器，在响应完成后，关闭连接。
• Cache-Control：用于指定缓存指令，缓存指令是单向的（响应中出现的缓存指令在请求中未必会出现），且是独立的（一个消息的缓存指令不会影响另一个消息处理的缓存机制）。

 

2.请求报头

在请求行之后会有0个或者多个请求报头，请求报头通知服务器关于客户端请求的信息。典型的请求报头如下所示:
• Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。
• User-Agent：发送请求的浏览器类型、操作系统等信息。
• Accept：客户端可识别的媒体类型列表，用于指定客户端接收哪些类型的信息。
• Accept-Charset   请求报头域用于指定客户端可以接受的字符集 。
• Accept-Encoding：客户端支持的压缩方式
• Accept-Language：表示浏览器所支持的语言和地区类型。
• Authorization 请求报头域主要用于证明客户端有权查看某个资源。
• Connection：是否需要长连接 keep-alive  close
• Transfer-Encoding：告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式。

3.响应报头

用于服务器传递自身信息的响应。常见的响应报头如下所示:
• Location：用于重定向接收者到一个新的位置，常用在更换域名的时候。
• Server：包含服务器用来处理请求的系统信息，与User-Agent请求报头是相对应的。

4.实体报头

实体报头用来定义被传送资源的信息，其既可用于请求也可用于响应。请求和响应消息都可以传送一 个实体。常见的实体报头如下所示:
• Content-Type：发送给接收者的实体正文的媒体类型。
• Content-Lenght：实体正文的长度。
• Content-Language：描述资源所用的自然语言。
• Content-Encoding：压缩方式
• Last-Modified：实体报头用于指示资源的最后修改日期和时间。
• Expires：实体报头给出响应过期的日期和时间。

 

 

八 请求头详解

 

1 ：language：Accept-Language 和content-language

<language>

用含有两到三个字符的字符串表示的语言码。

<locale>

完整的语言标签。除了语言本身之外，还会包含其他方面的信息，显示在中划线（"-"）后面。最常见的额外信息是国家或地区变种（如"en-US"）或者表示所用的字母系统（如"sr-Lat"）。其他变种诸如拼字法（"de-DE-1996"）等通常不被应用在这种场合。

*

任意语言；"*"表示通配符。

;q= (q-factor weighting)紧跟在所标识语言的后面

值代表优先顺序，用相对质量价值 表示，又称为权重。q是权重系数，范围 0 =< q <= 1，q 值越大，请求越倾向于获得其“;”之前的类型表示的内容，若没有指定 q 值，则默认为1，若被赋值为0，则用于提醒服务器哪些是浏览器不接受的内容类型。

多个参数项用逗号隔开。
 

示例：fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5

 

2 encoding content-encoding accept-encoding 编码类型 ： body 压缩类型

用于对特定媒体类型的数据进行压缩。accept-encoding代表浏览器支持的压缩方式，content-encoding 代表请求数据的压缩方式，

一般建议对数据尽可能地进行压缩，因此才有了这个消息首部的出现。不过对于特定类型的文件来说，比如jpeg图片文件，已经是进行过压缩的了。有时候再次进行额外的压缩无助于负载体积的减小，反而有可能会使其增大。

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

指令

• gzip

表示采用  Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。出于兼容性的考虑， HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 x-gzip 指令。

• compress

采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自UNIX系统的 compress 程序，该程序实现了前述算法。
与其同名程序已经在大部分UNIX发行版中消失一样，这种内容编码方式已经被大部分浏览器弃用，部分因为专利问题（这项专利在2003年到期）。

• deflate

采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。

• identity

用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。

• br

表示采用 Brotli 算法的编码方式。

示例

使用 gzip 方式进行压缩

客户端可以事先声明一系列的可以支持压缩模式，与请求一齐发送。 Accept-Encoding 这个首部就是用来进行这种内容编码形式协商的：

Accept-Encoding: gzip, deflate

服务器在 Content-Encoding 响应首部提供了实际采用的压缩模式：

Content-Encoding: gzip

需要注意的是，服务器端并不强制要求一定使用何种压缩模式。采用哪种压缩方式高度依赖于服务器端的设置，及其所采用的模块。

参考：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Content-Encoding

 

3 charset  Content-Type: application/json; charset=utf-8   Accept-Charset 指定字符集