RFC2616阅读记录

RFC文档阅读记录

前言

阅读一些作品之后总感觉少了点什么，感觉多少需要留下一些记录方便回忆或者参考，因此开坑，本系列作为学习RFC文档的记录。记录内容并不严格按照相应文档内容。本文先记录RFC2616关于 HTTP/1.1的内容。

一、 Hypertext Transfer Protocol

HTTP (Hypertext Transfer Protocol)是用于分布式、协作、超媒体信息
系统的应用层协议。它是一种通用的、无状态的协议。HTTP的一个特性是
数据表示的类型和协商，允许系统独立于正在传输的数据进行构建。

二、RFC2616阅读记录

1.HTTP/1.1由来

1990年，万维网全球信息使用HTTP/0.9进行Internet上原始数据的简单传输。 RFC 1945定义的HTTP/1.0协议中使用了MIME(Multipurpose Internet Mail Extensions)的框架，允许消息采用类似MIME的消息格式。但是当时未充分考虑到分层代理、缓存、持久连接、虚拟主机等影响。
因此，HTTP/1.1应运而生。

2.内容摘要

2.1部分术语（Terminology）

user agent（用户代理）
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.

proxy（代理）
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy MUST implement
both the client and server requirements of this specification. A
“transparent proxy” is a proxy that does not modify the request or
response beyond what is required for proxy authentication and
identification. A “non-transparent proxy” is a proxy that modifies
the request or response in order to provide some added service to
the user agent, such as group annotation services, media type
transformation, protocol reduction, or anonymity filtering. Except
where either transparent or non-transparent behavior is explicitly
stated, the HTTP proxy requirements apply to both types of
proxies

tunnel（隧道）
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections are closed.不作为隧道进行通信的任何
一方都可以使用内部缓存处理请求（应该是出于安全性考虑不使用本地缓存）

2.2 URI（Uniform Resource Identifiers）

统一资源标识符是统一资源定位符Uniform Resource Locators (URL) 以及统一资源命名符Names (URN)的联合。
URL格式： http_URL = “http:” “//” host [ “:” port ] [ abs_path [ “?” query ]]
IP地址的使用在url中应该尽可能避免使用（详见RFC1900 Renumbering Needs Work,主要介绍了IP重新编号的问题，比较了DNS与IP，并推荐使用域名代替IP在配置文件等中使用）,默认80端口.
URI规定是大小写不敏感的，并且一些保留及不安全字符等同于其“%”HEX HEX编码。如下等价
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html

2.3 Content Codings 与Transfer Codigns

内容编码与传输编码，内容编码值表示已经或可以应用于实体（entitty）的编码转换。内容编码主要用于压缩或以其他方式有效转换文档，而不会丢失其底层媒体类型的标识，也不会丢失信息。通常，实体以编码形式存储，直接传输，并且仅由接收方解码。打开控制台能找到请求头中有一项accept-encoding:gzip,deflate,br 响应头对应content-encoding 项为br.后者应用于实体主体（entity-body)，确保其在网络中的”安全传输“。两者区别在于后者是报文（message）的属性，而不是源实体的属性。传输编码中只定义了Chunked Transfer Coding ：块传输编码，块大小字段是一个十六进制数字字符串，指示块的大小。解决了发送前消息大小不确定的问题。

2.4 HTTP　Message

Message Types分为请求与响应。
Message Headers：请求头与响应头
Message Body ：The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response.The message-body differs from the entity-body only when a transfer-coding has been applied, as indicated by the Transfer-Encoding header field 。
message-body = entity-body |
Message Length：传输长度（由报文性质及分块机制等决定）
　General Header Fields

2.５ Request

	Method：GET和HEAD方法必须得到所有通用服务器的支持。所有其他方法都是可选的；

2.6 Response

	Status-Line： 主要包含状态代码和原因短语 如常见的 403 Forbidden
	1xx: Informational - Request received, continuing process
	2xx: Success - The action was successfully received, understood, and accepted
	3xx: Redirection - Further action must be taken in order to complete the request
	4xx: Client Error - The request contains bad syntax or cannot be fulfilled
	5xx: Server Error - The server failed to fulfill an apparently valid request
    HTTP状态码是可扩展的。

总结

到这里大致走完了前面7节，虽然英文原文大部分都认识，但夹杂术语加翻译功底还没到家，读起来还是有点费劲，术语名称部分参考了HTTP权威指南一书，且看该文档下来如同书中所讲RFC2616文档更是一本关于HTTP/1.1的参考手册，并不适合希望了解HTTP底层概念及设计动因、原理及具体实现区别者阅读，由于文档比较复杂且细节多，本人能力有限，第一次写格式也不太好，本章记录意义大于阅读意义，后面接两三篇争取这星期搞完，最后总结一下读后感。

https://www.rfc-editor.org/rfc/rfc2616.html