HyperText Transfer Protocol(HTTP)
HTTP是一个用于传输超媒体文档(hypermedia documents)的应用层协议,其主要使用场景是网络浏览器和网络服务器之间进行通信。
1. 信息内容:Web Page
浏览器中显示的页面叫做网页(Web Page),其通常由如下两部分构成:
HTML文件,描述对象和布局等信息
对象,单个页面中可能包含多个对象,这些对象可以是图片、文件、视频等。对象可能以URL形式给出
1.1 Hypertext Markup Language(HTML)
Hyper means over or above , 即"超"的意思。所谓超媒体、超文本,意指包括但不限于的意思。典型的超媒体文档类型为HTML。
HTML是一种用于创建网页的标准标记语言,和CSS、JavaScript一起构建了万维网(World Wide Web, WWW)的基础。通常我们可以按如下形式来理解三者的关系:
- HTML结构化元素:通过标记符号来标记要显示的网页中的各个基本元素如文字、图片甚至音视频等
- CSS呈现形式:定义不同呈现方式如字体、颜色、边距等
- JavaScript负责界面功能:定义不同组件的行为,形成交互
1.2 Uniform Resource Locator(URL)
Uniform Resource Identifier(URI) 是一个由字符组成的字符串,用于标示具体资源。URI代表的是一种象征,象征着网络中每一个资源都有唯一的标识符以便于访问。URL是URI的一种常见形式,另一种还有Uniform Resource Name(URN),两者区别是:
URN 类似于人名,标示一个资源名称
URL 类似于地址,标示如何找到该资源
以http://www.someSchool.edu/someDepartment/picture.gif
为例,URL通常由两部分组成:
- 存储对象的主机名,
www.someSchool.edu
- 主机中对象的具体路径,
/someDepartment/picture.gif
2. 通信流(flow)
HTTP使用TCP作为传输协议,Server与Client交互过程中会建立TCP连接,但并不会保存任何Client的状态信息,因此HTTP也成为无状态(stateless)协议。
计算机相互之间进行通讯通常有两种方式:
-
请求响应(request-response)
向对端主机发送请求后需等待响应,这类通信过程就是由一系列的单次通信构成,典型应用如网页浏览
-
单向(one-way )
向对端主机发送消息后无需等待回复,典型应用如邮件
2.1 TCP
如前文所述,HTTP通信方式属于请求响应类型,因此单次通信流程通常为:
- 建立TCP连接
- 发送HTTP消息(message, 应用层信息单元)
- 读取服务器响应
- 关闭TCP连接
由于HTTP为无状态协议(即每次通信间无关联),因此通常来讲,HTTP每次通信都是使用独立TCP连接的。大部分网络应用中,client和server会在一定时间内通信多次,从每次request和response是否通过同一TCP链接发送的角度来看,可以划分为两种:
- 短连接(non-persistent connections),每个request/response对均使用单独TCP链接
- 长连接(persistent connections),每个request/response对均使用同一TCP链接
在HTTP 0.9和1.0中,连接均会在单词请求响应后关闭,而TCP连接的建立和消亡需要经过三路握手、四路断开,因此需要一定额外时间开销。有鉴于此,从HTTP 1.1开始,所有连接默认为长连接。更进一步地,如果不必每个单次通信都需等待响应后才能继续下一个通信,则可以实现流水线技术,提高并发量。
2.2 Message格式
解决了连接的问题,剩下的就是消息格式了。前面提过,通信的基础是有效的转换和逆转换,转换需要规则,规则就是协议。对于HTTP而言,存在两种规则,分别为request和response。
HTTP 1.1及之前版本中,message均是可读性强字符。在HTTP 2中,这些消息将被先封装至二进制结构frame中,并通过frame header进行其他如复用等配置。
2.2.1 Request
先放一个示例:
GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
(data data data data data ...)
可以看出,组成元素均为可读性强的ASCII字符,具体格式则可进一步细分为如下结构:
2.2.2 Response
HTTP/1.1 200 OK
Connection: close
Date: Tue, 09 Aug 2011 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)
3. 字段定义
3.1 Request methods
HTTP请求中定义了method字段以标明希望在URL上执行的操作,而该资源将如何呈现、是否已存在或将被动态创建,均基于服务器的实现本身。主流应用中,通常会选择实现如下方法:
-
GET
请求所需资源,该请求除获取数据外不应产生其他效果
-
HEAD
功能与GET相当,区别在于响应中不包括具体数据,即不含response body。可以理解为GET的轻量级,只查看元信息而不实际获取。
-
POST
将请求body中内容推送至服务器,或是存储在URI指定的资源下,或是其他实现形式
-
PUT
将请求body中内容存储至服务器中URI指定位置,如该URI已有资源,将被修改;如无资源,则将创建
-
DELETE
删除服务器中指定资源
-
TRACE
告知服务器回传所收请求,以便客户端确认链路中是否发生修改行为
-
OPTIONS
返回服务器在指定URL上所支持的方法,如URL为'*',则查询对象为服务器本身
-
CONNECT
告知服务器去返回指定URL,并将其获取到的Response转发回请求客户端,相当于代理,网页开发中并不常用,仅预留做管理
-
PATCH
对资源进行局部修改操作
HTTP Method | RFC | Request Has Body | Response Has Body | Safe | Idempotent | Cacheable |
---|---|---|---|---|---|---|
GET | RFC 7231 | Optional | Yes | Yes | Yes | Yes |
HEAD | RFC 7231 | No | No | Yes | Yes | Yes |
POST | RFC 7231 | Yes | Yes | No | No | Yes |
PUT | RFC 7231 | Yes | Yes | No | Yes | No |
DELETE | RFC 7231 | No | Yes | No | Yes | No |
CONNECT | RFC 7231 | Yes | Yes | No | No | No |
OPTIONS | RFC 7231 | Optional | Yes | Yes | Yes | No |
TRACE | RFC 7231 | No | Yes | Yes | Yes | No |
PATCH | RFC 5789 | Yes | Yes | No | No | No |
3.2 Status codes
自HTTP 1.0开始,响应以状态行开始,而状态行中进一步包含了一个状态码(status code)及对应的文字说明。状态码分为五类,为了便于管理和更加直观表示,第一个数字用于标示响应的类型。
-
1xx Informational responses
标明请求已被接收并解析,常用于服务器需较长时间处理请求时告知客户端正在处理,且客户端需等待最终的回复。
- 100 Continue
- 101 Switching Protocols
- 102 Processing
- 103 Early Hints
-
2xx Success
标明请求已被接收、解析且已生效。
- 200 OK
- 201 Created
- 202 Accepted
- 203 Non-Autoritative Information (Since HTTP/1.1)
- 204 No Content
- 205 Reset Content
- 206 Partial Content
- 207 Multi-Status
- 208 Already Reported
- 226 IM Used
-
3xx Redirection
标明客户端需要采取额外措施来完成整个请求,通常用于URL重定向。
- 300 Multiple Choices
- 301 Moved Permanently
- 302 Found
- 303 See Other
- 304 Not Modified
- 305 Use Proxy
- 306 Switch Proxy
- 307 Temporary Redirect
- 308 Permanent Redirect
-
4xx Client errors
标明可能由客户端引发的错误,除HEAD方法外,其余情况中这类Response将会在Body中包含错误情况的详细说明,以及是临时或永久状况。
- 400 Bad Request
- 401 Unauthorized
- 402 Payment Required
- 403 Forbidden
- 404 Not Found
- 405 Method Not Allowed
- 406 Not Acceptable
- 407 Proxy Authentication
- 408 Request Timeout
- 409 Conflict
- 410 Gone
- 411 Length Required
- 412 Precondition Failed
- 413 Payload Too Large
- 414 URI Too Long
- 415 Unsupported Media Type
- 416 Range Not Satisfiable
- 417 Expectation Failed
- 418 I'm a teapot
- 421 Misdirected Request
- 422 Unprocessable Entity
- 423 Locked
- 424 Failed Dependency
- 426 Upgrade Required
- 428 Precondition Required
- 429 Too Many Requests
- 431 Request Header Fields Too Large
- 451 Unavailable For Legal Reasons
-
5xx Server error
标明可能由服务器本身引发的错误。
- 500 Internal Server Error
- 501 Not Implemented
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
- 505 HTTP Version Not Supported
- 506 Variant Also Negotiates
- 507 Insufficient Storage
- 508 Loop Detected
- 510 Not Extended
- 511 Network Authentication Required
4. 高级控制
4.1 Cache
所谓缓存(Cache),就是指相比服务器本身,在更靠近客户端的链路中设置一个额外的服务器副本。简单来看,缓存技术有两大优势:
- 通过分流,降低了服务器本身负载,提高整体并发
- 缩短链路带宽、长度,降低传输引发的延时
因此,缓存技术本质上是降低了单次请求的响应时长,从而提升网络体验。
The Conditional GET
然而大部分时候,副本带来了高可靠性,也带来了同步问题。实际服务器中内容可能随时间推移会发生修改,此时副本服务器中的数据就是相对过期了的,那么必要的同步就势在必行。
什么是必要的同步,就是只有比较数据后发现有更新才进行同步,否则只是无谓的拷贝,占用带宽。判断数据是否发生更新可以从数据本身出发,也可以只从数据标签即元数据出发,只要记录的数据最后更新时间一致,就可以判定数据不必更新,否则,就有更新的必要了。HTTP中这种机制叫做conditional GET,而更新的时间,就是通过Request中的If-modified-since
字段给出。
GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Web, 7 Sep 2011 09:23:24
4.2 Session and Cookie
前面提到,HTTP是无状态协议,就是说HTTP服务器不会在多个请求之间维护用户信息。但实际应用中,又往往存在这种刚性需求,典型的如购物、新闻浏览等。为了实现宾至如归的错觉,增加用户的黏度,HTTP采用了会话(Session)和Cookie技术。
会话,相当于一次对话。一次对话肯定包括至少一次交互,同样一次会话也至少包括一个请求响应对。因此会话就是由一系列的请求响应对组成。要想在一系列动作中保持某种状态,比较通用的方法就是在动作之外,维护一个变量或者文件,而Cookie的组成元素中,文件就是重要的一环。
Cookie
Cookie技术由四大组件组成:
- Response中Cookie header line用于返回服务器为用户所分配的Cookie ID
- Request中Cookie header line用于告知服务器请求来自于哪一个为用户的Cookie ID
- 用户客户端上本地存储维护的Cookie文件,记录用户行为
- 网站本身的后台数据库,保存了用户与Cookie ID间映射关系等数据
Cookie的具体使用过程如上图所示,总的来讲,就是通过独立第三发信息(Cookie ID、数据库、Cookie文件)来记录用户信息,并在会话中相关请求响应对中标记,保持服务器与客户端间的同步,实现状态维护。
5. 小结
本篇概述了HTTP的大部分内容,如有兴趣进一步学习研究,可参考相关Spec.