HTTP协议总结

gopher 其他 226 次浏览 没有评论

请求过程

 

HTTP/0.9

HTTP 是基于 TCP/IP 协议的应用层协议。它不涉及数据包 packet传输,主要规定了客户端和服务器之间的通信格式,默认使用 80 端口。
最早版本是
1991年发布的 0.9 版。该版本极其简单,只有一个命令 GET

GET /index.html

上面命令表示,TCP 连接(connection)建立后,客户端向服务器请求(request)网页index.html
协议规定,服务器只能回应
HTML格式的字符串,不能回应别的格式。

  1. <body>Hello World</body>
  2. </html>

 

服务器发送完毕,就关闭TCP连接。

HTTP/1.0

简介

19965月,HTTP/1.0 版本发布,内容大大增加。

  • 首先,任何格式的内容都可以发送。这使得互联网不仅可以传输文字,还能传输图像、视频、二进制文件。这为互联网的大发展奠定了基础。
  • 其次,除了GET命令,还引入了POST命令和HEAD命令,丰富了浏览器与服务器的互动手段。
  • 再次,HTTP请求和回应的格式也变了。除了数据部分,每次通信都必须包括头信息HTTP header),用来描述一些元数据。
  • 其他的新增功能还包括状态码( status code )、 多字符集支持 、多部分发送( multi-part type )、 权限(authorization缓存(cache内容编码(content encoding 。

请求格式

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

第一行是请求命令,必须在尾部添加协议版本 HTTP/1.0。后面就是多行头信息,描述客户端的情况。

回应格式

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Encoding: gzip
Content-Length: 3495
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84


<
html>
<
body>Hello World</body>
</
html>

回应的格式是 头信息 + 一个空行(\r\n+ 数据

Content-Type
服务器回应的时候,必须告诉客户端,数据是什么格式,这就是Content-Type字段的作用。
下面是一些常见的
Content-Type字段的值。

text/plain
text/html
text/css
image/jpeg

image/png
image/svg+xml
audio/mp4
video/mp4
application/javascript
application/pdf
application/zip
application/atom+xml

这些数据类型总称为 MIME type ,每个值包括一级类型和二级类型,之间用斜杠分隔。
MIME type 还可以在尾部使用分号,添加参数。

Content-Type: text/html; charset=utf-8

上面的类型表明,发送的是网页,而且编码是UTF-8
客户端请求的时候,可以使用
Accept字段声明自己可以接受哪些数据格式。

Accept: */*

上面代码中,客户端声明自己可以接受任何格式的数据。
MIME type 不仅用在 HTTP 协议,还可以用在其他地方,比如HTML网页。

<meta http-equiv=“Content-Type” content=“text/html; charset=UTF-8”/>

Content-Encoding

由于发送的数据可以是任何格式,因此可以把数据压缩后再发送。 Content-Encoding 字段说明数据的压缩方法。

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate

客户端在请求时,用 Accept-Encoding 字段说明自己可以接受哪些压缩方法

Accept-Encoding: gzip, deflate

Content-Length

一个TCP连接现在可以传送多个回应,势必就要有一种机制,区分数据包是属于哪一个回应的。这就是Content-length字段的作用,声明本次回应的数据长度。

Content-Length: 3495

上面代码告诉浏览器,本次回应的长度是3495个字节,后面的字节就属于下一个回应了。

缺点

HTTP/1.0 版的主要缺点是,每个TCP连接只能发送一个请求。发送数据完毕,连接就关闭,如果还要请求其他资源,就必须再新建一个连接。
TCP连接的新建成本很高,因为需要客户端和服务器三次握手,并且开始时发送速率较慢(slow start)。所以,HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多,这个问题就愈发突出了。
为了解决这个问题,有些浏览器在请求时,用了一个非标准的
Connection 字段。

Connection: keep-alive

这个字段要求服务器不要关闭TCP连接,以便其他请求复用。服务器同样回应这个字段。

HTTP/1.1

19971月,HTTP/1.1 版本发布,只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议,一直用到了20年后的今天,直到现在还是最流行的版本

持久连接

1.1 版的最大变化,就是引入了持久连接( persistent connection ),即TCP连接默认不关闭,可以被多个请求复用,不用声明 Connection: keep-alive
不过,规范的做法是,客户端在最后一个请求时,发送
Connection: close ,明确要求服务器关闭TCP连接。
目前,对于同一个域名,大多数浏览器允许同时建立
6个持久连接。

管道机制

1.1 版还引入了管道机制(pipelining),即在同一个TCP连接里面,客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。
举例来说,客户端需要请求两个资源。以前的做法是,在同一个
TCP连接里面,先发送A请求,然后等待服务器做出回应,收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求,但是服务器还是按照顺序,先回应A请求,完成后再回应B请求。

分块传输编码

使用 Content-Length 字段的前提条件是,服务器发送回应之前,必须知道回应的数据长度。
对于一些很耗时的动态操作来说,这意味着,服务器要等到所有操作完成,才能发送数据,显然这样的效率不高。更好的处理方法是,产生一块数据,就发送一块,采用
流模式stream)取代缓存模式buffer)。
因此,
1.1版规定可以不使用 Content-Length 字段,而使用分块传输编码chunkedtransfer encoding)。只要请求或回应的头信息有 Transfer-Encoding 字段,就表明回应将由数量未定的数据块组成。

Transfer-Encoding: chunked

每个非空的数据块之前,会有一个16进制的数值,表示这个块的长度。最后是一个大小为0的块,就表示本次回应的数据发送完了。下面是一个例子。

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
c
on
8 s
equence
0

其他功能

1.1版还新增了许多动词方法: PUTPATCHHEADOPTIONSDELETE
另外,客户端请求的头信息新增了Host字段,用来指定服务器的域名。

Host: www.example.com

有了Host字段,就可以将请求发往同一台服务器上的不同网站,为虚拟主机的兴起打下了基础。

缺点

虽然1.1版允许复用TCP连接,但是同一个TCP连接里面,所有的数据通信是按次序进行的。服务器只有处理完一个回应,才会进行下一个回应。要是前面的回应特别慢,后面就会有许多请求排队等着。这称为队头堵塞Head-of-line blocking
为了避免这个问题,只有两种方法:一是减少请求数,二是同时多开持久连接。这导致了很多的网页优化技巧,比如合并脚本和样式表、将图片嵌入CSS代码、域名分片(domainsharding)等等

HTTP/2.X

2015年,HTTP/2 发布。它不叫 HTTP/2.0,是因为标准委员会不打算再发布子版本了,下一个新版本将是 HTTP/3

二进制协议

HTTP/1.1 版的头信息肯定是文本(ASCII编码),数据体可以是文本,也可以是二进制。 HTTP/2 则是一个彻底的二进制协议,头信息和数据体都是二进制,并且统称为frame):头信息帧和数据帧。

多工

HTTP/2 复用TCP连接,在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应,这样就避免了队头堵塞
举例来说,在一个
TCP连接里面,服务器同时收到了A请求和B请求,于是先回应A请求,结果发现处理过程非常耗时,于是就发送A请求已经处理好的部分, 接着回应B请求,完成后,再发送A请求剩下的部分。
这样双向的、实时的通信,就叫做多工(
Multiplexing)。

服务器推送

HTTP/2 允许服务器未经请求,主动向客户端发送资源,这叫做服务器推送(serverpush)。
常见场景是客户端请求一个网页,这个网页里面包含很多静态资源。正常情况下,客户端必
须收到网页后,解析HTML源码,发现有静态资源,再发出静态资源请求。其实,服务器可以预期到客户端请求网页后,很可能会再请求静态资源,所以就主动把这些静态资源随着网页一起发给客户端了。

响应状态码

状态码类别

1XX Informational(信息性状态码)接收的请求正在处理
2XX Success(成功状态码) 请求正常处理完毕
3XX Redirection(重定向状态码) 需要进行附加操作以完成请求
4XX Client Error(客户端错误状态码)服务器无法处理请求
5XX Server Error(服务器错误状态码)服务器处理请求出错

常见状态码

200:请求被正常处理
301:永久性重定向
302:临时重定向
401:请求需要认证
403:请求的对应资源禁止被访问
404:服务器无法找到对应资源
500:服务器内部错误
503:服务器正忙

GetPost的区别

  • get 重点在从服务器上获取资源, post 重点在向服务器发送数据;
  • get 传输数据是通过 URL 请求,以 field(字段)= value 的形式,置于 URL 后,并用”?”连接,多个请求数据间用”&”连接,如http://127.0.0.1/Test/login.action?name=admin&password=admin ,这个过程用户是可见的;
  • post 传输数据通过 Http post 机制,将字段与对应值封存在请求实体中发送给服务器,这个过程对用户是不可见的;
  • Get 传输的数据量小,因为受 URL 长度限制,但效率较高; Post 可以传输大量数据,所以上传文件时只能用 Post 方式;
  • get 是不安全的,因为URL是可见的,可能会泄露私密信息,如密码等; post get 安全性较高;

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Go