计算机网络——HTTP协议

来源：互联网发布：msp430中文数据手册编辑：程序博客网时间：2024/06/04 18:37

HTTP协议的发展历史

以下内容：
本部分参考资料为《HTTP协议的历史演变和设计思路》

HTTP 0.9

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

GET /index.html

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

<html>    <body>hello world</body></html>

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

HTTP 1.0

1996年5月，HTTP 1.0版本发布，内容大大增加。
首先，任何格式的内容都可以发送，这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件等。
另外，除了GET命令，还引入了POST命令和HEAD命令。
并且，HTTP请求和回应的格式也变了。除了数据部分，每次通信必须包括头信息(HTTP Header),用来描述一些元数据。
其他新增功能还包括状态码、多字符集支持、多部分发送、权限、缓存、内容编码等。

请求格式

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

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

响应格式

服务器的响应如下

HTTP/1.0 200 OKContent-Type: text/plainContent-Length: 137582Expires: Thu, 05 Dec 1997 16:00:00 GMTLast-Modified: Wed, 5 August 1996 15:55:28 GMTServer: Apache 0.84<html>    <body>hello world</body></html>

回应的格式是”头信息+一个空行(\r\n)+数据”。其中，第一行是”协议版本+状态码(status code)+状态描述”

Content-type字段

关于字符编码，1.0版规定，头信息必须是ASCII码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是Content-Type字段的作用。
下面是常见的Content-Type字段的值

text/plain
text/html
text/css
image/jpeg
image/png
image/svg+xml
audio/mp4
video/mp4
application/pdf
application/zip
application/atom+xml

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

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

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

Accept: */*

Content-Encoding字段

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

Content-Encoding:gzipContent-Encoding:compressContent-Encoding:deflate

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

Accept-Encoding:gzip, deflate

缺点

HTTP/1.0主要缺点就是每次TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须新建一个连接。
TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢，所以HTTP/1.0版本的性能较差。

HTTP 1.1

1997年1月，HTTP/1.1版本发布，只比1.0晚了半年。

持久连接

1.1版本最大的变化就是引入持久连接(persistent connection),即TCP连接默认不关闭，可以被多个请求复用。
客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过规范的做法是，客户端在最后一个请求你是发送Connection:close，明确要求服务器关闭TCP连接。

管道机制

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

Content-Length字段

一个TCP连接限制可以传送多个回应，就必须要有一种机制，区分数据包属于哪一个回应。这就需要Content-type字段的作用，声明本次回应的数据长度

Content-Length:3495

上面的字段高速浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。
在1.0版本中，Content-Length字段不是必须的，因为浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了

分块传输编码

1.1版本规定可以不使用Content-Length字段，而使用分块传输编码。

其他功能

1.1版本还增加了:PUT, PATCH, HEAD, OPTIONS, DELETE方法。
另外客户端请求的头信息新增了HOST字段，用来指定服务器的域名。
有了Host字段，就可以将请求发往同一台服务器上不同的网站，为虚拟主机的兴起打下了基础。

缺点

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

HTTP/2

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

二进制协议

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

多工

HTTP/2复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求和回应，而不用按照顺序一一对应，这样就避免了”队头阻塞”。

数据流

HTTP/2将每个请求或回应的数据包，成为一个数据流。每个数据里都有一个独一无二的编号。数据包发送时，都必须标记数据流ID，另外还规定客户端发出的数据流，ID一律为奇数，服务器发出的，ID一律为偶数。客户端还可以指定数据流的优先级，优先级越高，服务器就会越早回应。
另外数据流发送到一半的时候，客户端和服务器可以发送信号(RST_STREAM帧)，取消这个数据流。1.1版本取消数据流的唯一方法就是关闭TCP连接。这就是说HTTP/2可以取消某一次请求，同时保证TCP连接还打开这。

头信息压缩

HTTP协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如cookie和user agent，一模一样的内容，每次请求必须附带，浪费很多宽带，也影响速度。
HTTP/2对这一点做了优化，引入了头信息压缩机制。一方面头信息使用gzip或compress压缩后再发送；另一方面客户端和服务器同时维护一张头信息表，所有字段都会存入这个表生成一个索引号，以后就不发送同样字段，只发送索引号，这样就提高了速度。

服务器推送

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

统一资源定位符(URL, Uniform Resource Locator)：

URL提供一种定位网络资源的手段，但这些资源可以通过各种不同的方案(比如http、ftp、smtp等)来访问。

URL语法:

大多数URL方案的语法的通用格式，基本可以由9个部分构成：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

最主要的包括三个部分：协议(或者成为方案scheme)、页面所在机器的DNS、唯一指向特定页面的路径。
eg. http://www.cs.washington.edu/index.html
该URL由三部分组成：协议(http)、主机的DNS(www.cs.washington.edu)和路径名(index.html)

URL默认使用的是7位二进制码表示的ASCII字符集。在URL中表示各种不安全的字符使用一种转义的方法。这种转义包含一个”%”，后面跟两个表示字符ASCII码的十六进制数。

当点击该链接时，会发生如下步骤：

浏览器请求DNS查询服务器www.cs.washington.edu的IP地址
DNS返回128.208.3.88
浏览器与128.208.3.88机器的80端口建立TCP连接
浏览器发送HTTP报文，请求/index.html页面
www.cs.washington.edu服务器发回页面作为HTTP响应
浏览器显示页面/index.html
如果短期内没有向同一个服务器发出其他请求，那么释放TCP连接。

HTTP是一个简单的请求-响应协议，运行在TCP协议之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出，而消息内容则具有一个类似MIME的格式。
在Web早期HTTP 1.0中，连接被建立起来以后浏览器只发送一个请求，之后一个响应消息被发回来，再然后TCP连接就被释放了。在那时，整个Web页面通常只包含HTML文本，因此这种连接方式足够使用。但是随着Web的发展，页面内含有大量的嵌入式内容链接，如图片等内容。建立一个单独的TCP连接来传输每个图标的操作方式代价太高。
正是这种现象导致HTTP 1.1的诞生。它支持持续连接。

HTTP每个请求都会得到一个响应，每个响应消息由一个状态行及可能的附加信息组成。状态行包括一个3位数字的状态码，该状态码指明了这个请求是否被满足，如果没有满足，那么原因是什么。
第一个数字把响应分成5大组，如表所示

代码含义例子 1XX 信息 100=服务器统一处理客户请求 2XX 成功 200=请求成功； 204=没有内容 3XX 重定向 301=移动页面； 304=缓存的页面仍然有效 4XX 客户错误 403=禁止页面； 404=页面没找到 5XX 服务器错误 500=服务器内部错误； 503=稍后再试

消息头：请求行(如GET)后面可能还有额外的信息，称为请求头，响应消息也有响应头

头类型内容 User-Agent 请求有关浏览器及其平台的信息 Accept 请求客户可处理的页面类型 Accept-Charset 请求客户可接受的字符集 Accept-Encoding 请求客户可处理的页面编码 Accept-Language 请求客户可处理的自然语言 If-Modified-Since 请求检查新鲜度的时间和日期 If-None-Match 请求先前为检查新鲜度而发送的标签 Host 请求服务器的DNS名字 Authorization 请求列出客户的信任凭据 Referer 请求发出请求的先前URL Cookie 请求给服务器发回Cookie的先前URL Set-Cookie 响应客户存储的Cookie Server 响应关于服务器的信息 Content-Encoding 响应内容如何编码(比如: gzip) Content-Language 响应页面使用的自然语言 Content-Length 响应页面以字节计的长度 Content-Type 响应页面的MIME类型 Content-Range 响应标识了页面内容的一部分 Last-Modified 响应页面最后修改的时间和日期 Expires 响应页面不再有效的时间和日期 Locatioin 响应告诉客户向谁发送请求 Accept-Ranges 响应指出服务器能接受的请求的字节范围 Date 请求/响应发送消息的日期和时间 Range 请求/响应标识一个页面的一部分 Cache-Control 请求/响应指示如何处理缓存 ETag 请求/响应页面内容的标签 Upgrade 请求/响应发送方希望切换的协议

0 0