带新手走进神秘的HTTP协议

本文介绍了HTTP协议的基本概念、历史发展、操作过程及特点等内容。详细解释了请求与响应报文的结构,以及Cookie如何实现状态管理。

在开发的时候经常需要访问网络,比如Android就有好多这方面的框架:Volley、OkHttp、Retrofit等,当你看这些框架源码时,可能会很好奇关于http的部分,它的首部字段是什么意思,http是如何工作的??等等,希望这篇文章会为你解惑。

一、概念

协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则,超文本传输协议(HTTP)是一种通信协议,它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器。

HTTP协议,即超文本传输协议(Hypertext transfer protocol)。是一种详细规定了浏览器和万维网(WWW = World Wide Web)服务器之间互相通信的规则,通过因特网传送万维网文档的数据传送协议。

HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效,使网络传输减少。它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。

HTTP是一个应用层协议,由请求和响应构成,是一个标准的客户端服务器模型。HTTP是一个无状态的协议。

在Internet中所有的传输都是通过TCP/IP进行的。HTTP协议作为TCP/IP模型中应用层的协议也不例外。HTTP协议通常承载于TCP协议之上,有时也承载于TLS或SSL协议层之上,这个时候,就成了我们常说的HTTPS。如下图所示:

HTTP默认的端口号为80,HTTPS的端口号为443。

浏览网页是HTTP的主要应用,但是这并不代表HTTP就只能应用于网页的浏览。HTTP是一种协议,只要通信的双方都遵守这个协议,HTTP就能有用武之地。比如咱们常用的QQ,迅雷这些软件,都会使用HTTP协议(还包括其他的协议)。

二、简史

HTTP/0.9
HTTP 于 1990 年问世。那时的 HTTP 并没有作为正式的标准被建立。现在的 HTTP 其实含有 HTTP1.0 之前 版本的意思,因此被称为 HTTP/0.9。

HTTP/1.0

HTTP 正式作为标准被公布是在 1996 年的 5 月,版本被命名为 HTTP/1.0,并记载于 RFC1945。虽说是初 期标准,但该协议标准至今仍被广泛使用在服务器端。
RFC1945 - Hypertext Transfer Protocol -- HTTP/1.0
http://www.ietf.org/rfc/rfc1945.txt 

HTTP/1.1

1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的标准是 RFC2068,之后发布的修订版 RFC2616 就是当前的最新版本。
RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1
http://www.ietf.org/rfc/rfc2616.txt 
可见,作为 Web 文档传输协议的 HTTP,它的版本几乎没有更新。新一代 HTTP/2.0 正在制订中,但要达到 较高的使用覆盖率,仍需假以时日。

三、统一资源定位符

URL 的一般形式是:

<URL的访问方式>://<主机>:<端口>/<路径>

四、HTTP 的操作过程 

  1. 每个Web站点都运行一个服务器进程,它不断地监听TCP的端口80,以便发现是否有向它发来连接请求;
  2. 一旦收到请求并建立了TCP连接之后,浏览器就向服务器发出某个页面的请求,服务器接着就返回请求的页面作响应;
  3. 最后连接被释放。这之间一系列信息的传输都遵循HTTP。 

五、Web工作过程

上图用户点击鼠标后所发生的事件:

(1) 浏览器分析超链指向页面的 URL;

(2) 浏览器向 DNS 请求解析 www.tsinghua.edu.cn 的 IP 地址;

(3) 域名系统 DNS 解析出清华大学服务器的 IP 地址;

(4) 浏览器与服务器建立 TCP 连接;

(5) 浏览器遵循HTTP协议发出取文件命令:

      GET /chn/yxsz/index.htm;

(6) 服务器给出响应,把文件 index.htm 发给浏览器;

(7) TCP 连接释放;

(8) 浏览器显示“清华大学院系设置”文件 index.htm 中的所有文本。

六、HTTP 的报文种类 

HTTP 有两类报文:

    请求报文——从客户向服务器发送请求报文。

    响应报文——从服务器到客户的回答。 

6.1 HTTP 的报文结构

 6.1 请求报文

报文由三个部分组成,即开始行、首部行和实体主体

在请求报文中,开始行就是请求行。

1.  方法:

方法”是面向对象技术中使用的专门名词。所谓“方法”就是对所请求的对象进行的操作,因此这些方法实际上也就是一些命令。因此,请求报文的类型是由它所采用的方法决定的。

HTTP 请求报文的一些方法 

 

2.URL

“URL”是所请求的资源的 URL。

3.版本

“版本”是 HTTP 的版本。

4.一个请求报文的例子:

 

6.2 响应报文

响应报文的开始行是状态行。

状态行包括三项内容,即 HTTP 的版本状态码,以及解释状态码的简单短语

状态码都是三位数字 :

  • 1xx 表示通知信息的,如请求收到了或正在进行处理。
  • 2xx 表示成功,如接受或知道了。
  • 3xx 表示重定向,表示要完成请求还必须采取进一步的行动。
  • 4xx 表示客户的差错,如请求中有错误的语法或不能完成。
  • 5xx 表示服务器的差错,如服务器失效无法完成请求。 

一个响应报文的例子:

6.3 使用WireShark实例分析

下面是一个用wireShark获取的http协议包:

可以看到这是post方法、url:/pcsuiteprofile/api/updateinfo?u=38e37ccd&len=24

版本:HTTP/1.1  \r\n:回车换行

首部字段:Host、Accept、Content-Type、Content-Length等等。

展开Post,具体分析,如图:

 

选中post,下边的16进制中显示的是:50 4f 53 54正好是POST四个字母对应的16进制ASCII,可以自行去对比ASCII。

如果你不会用wireShark,可以看下这篇文章:https://community.emc.com/message/818739#818739,只看一就够用了。

 七、使用 Cookie 的状态管理

 HTTP 是无状态协议,它不对之前发生过的请求和响应的状态进行管理。也就是说,无法根据之前的状态进行本次的请求处理。
Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息,通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时,客户端会自动在请求报文中加入 Cookie 值后发送出去。
服务器端发现客户端发送过来的 Cookie 后,会去检查究竟是从哪一个客户端发来的连接请求,然后对比服务 器上的记录,最后得到之前的状态信息。
  1. 没有 Cookie 信信息状态下的请求 

上图展示了发生 Cookie 交互的情景,HTTP 请求报文和响应报文的内容如下。

1. 请求报文(没有 Cookie 信息的状态)

GET/reader/HTTP/1.1
Host:hackr.jp
*首部字段内没有Cookie的相关信息

2. 响应报文(服务器端生成 Cookie 信息) 

HTTP/1.1200OK
Date:Thu,12Jul201207:12:20GMT
Server:Apache
<Set-Cookie:sid=1342077140226724;path=/;expires=Wed,10-Oct-1207:12:20GMT>
Content-Type:text/plain;charset=UTF-8

3. 请求报文(自动发送保存着的 Cookie 信息)

GET/image/HTTP/1.1
Host:hackr.jp
Cookie:sid=1342077140226724

有关请求报文和响应报文内Cookie 对应的首部字段,请参考之后的章节。

八、特点

HTTP协议永远都是客户端发起请求,服务器回送响应。这样就限制了使用HTTP协议,无法实现在客户端没有发起请求的时候,服务器将消息推送给客户端。

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

无状态协议:
协议的状态是指下一次传输可以“记住”这次传输信息的能力。
http是不会为了下一次连接而维护这次连接所传输的信息,为了保证服务器内存。
比如客户获得一张网页之后关闭浏览器,然后再一次启动浏览器,再登陆该网站,但是服务器并不知道客户关闭了一次浏览器。
由于Web服务器要面对很多浏览器的并发访问,为了提高Web服务器对并发访问的处理能力,在设计HTTP协议时规定Web服务器发送HTTP应答报文和文档时,不保存发出请求的Web浏览器进程的任何状态信息。这有可能出现一个浏览器在短短几秒之内两次访问同一对象时,服务器进程不会因为已经给它发过应答报文而不接受第二期服务请求。由于Web服务器不保存发送请求的Web浏览器进程的任何信息,因此HTTP协议属于无状态协议(Stateless Protocol)。

HTTP协议是无状态的和Connection: keep-alive的区别:
无状态是指协议对于事务处理没有记忆能力,服务器不知道客户端是什么状态。从另一方面讲,打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。
HTTP是一个无状态的面向连接的协议,无状态不代表HTTP不能保持TCP连接,更不能代表HTTP使用的是UDP协议(无连接)。
从HTTP/1.1起,默认都开启了Keep-Alive,保持连接特性,简单地说,当一个网页打开完成后,客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭,如果客户端再次访问这个服务器上的网页,会继续使用这一条已经建立的连接。
Keep-Alive不会永久保持连接,它有一个保持时间,可以在不同的服务器软件(如Apache)中设定这个时间。

注:本篇文章只是对http进行了简单的介绍,如果你想知道http的首部字段是什么意思,Accept、User-Agent、Connection等,https又是什么,欢迎看之后的更新。

转发请注明出处:http://www.cnblogs.com/jycboy/p/http1.html 

 

超 文本传输协议HTTP)是一种为分布式,合作式,超媒体信息系统。它是一种通用的,无状态(stateless)的协议,除了应用于超文本传输外,它也 可以应用于诸如名称服务器和分布对象管理系统之类的系统,这可以通过扩展它的请求方法,错误代码和报头[47]来实现。HTTP的一个特点是数据表现形式 是可输入的和可协商性的,这就允许系统能被建立而独立于数据传输。 目录 1 引论 1.1 目的 1.2 要求 1.3 术语 1.4 总体操作 2 符号习惯和一般语法 2.1 扩充的BNF(扩充的 巴科斯-诺尔范式) 2.2基本规则 (basic rule) 3 协议参数 3.1 HTTP版本 3.2 统一资源标识符(URI) 3.2.1一般语法 3.2.2 http URL 3.2.3 URI 比较 3.3 日期/时间格式(Date/Time Formats) 3.3.1完整日期 (Full Date) 3.3.2 Delta Seconds 3.4 字符集 3.4.1丢失的字符集(Missing Charset) 3.5 内容编码(Content Codings) 3.6 传输编码 (Transfer Codings) 3.6.1块传输编码(Chunked Transfer Coding) 3.7 媒体类型(Media Type) 3.7.1规范化和文本缺省 (Canonicalization and Text Defaults) 3.7.2多部分类型(Multipart type) 3.8 产品标记 (product Tokens) 3.9 质量值(Quality Values) 3.10 语言标签 (Language Tags) 3.11 实体标签 (Entity Tags) 3.12 范围单位(Range Units) 4 HTTP消息 4.1 消息类型(Message Types) 4.2 消息头 (Message Headers) 4.3 消息主体 (Message Body) 4.4 消息的长度(Message Length) 4.5 常用头域(General Header Fields) 5 请求(Request) 5.1 请求行 (Request-Line) 5.1.1方法 (Method) 5.1.2请求URL(Request-URI) 5.2请求资源 (The Resource Identified by a Request) 5.3请求报头域 (Request Header Fields) 6 响应 (Response) 6.1 状态行 (Status-Line) 6.1.1状态码与原因短语 (Status Code and Reason Phrase) 7 实体(Entity) 7.1 实体报文域(Entity Header Fields) 7.2 实体主体(Entity Body) 7.2.1类型(Type) 7.2.2实体主体长度(Entity Length) 8 连接 8.1 持续连接(Persistent Connection)。 8.1.1目的 8.1.2总体操作 8.1.2.1 协商(Negotiation) 8.1.2.2 流水线(pilelining) 8.1.3代理服务器 (Proxy Servers) 8.1.4实际的考虑 (Practical Considerations) 8.2 消息传送要求(Message Transmission Requirements) 8.2.1持续连接与流量控制 (Persistent Connections and Flow Control) 8.2.2监视连接中出错状态的消息 8.2.3 100状态码的用途 8.2.4服务器过早关闭连接时客户端的行为 9 方法定义(Method Definitions) 9.1 安全和等幂(Idempotent)方法 9.1.1安全方法(Safe Methods) 9.1.2等幂方法(Idempotent Mehtods) 9.2 OPTIONS(选项) 9.3 GET 9.4 HEAD 9.5 POST 9.6 PUT 9.7 DELETE(删除) 9.8 TRACE 9.9 CONNECT(连接) 10.状态码定义 10.1 通知的 1xx 10.1.1 100 继续 (Continue) 10.1.2 101切换协议 (Switching Protocols) 10.2 成功 2xx 10.2.1 200 OK 10.2.2 201 已创建(Created) 10.2.3 202 接受(Accepted) 10.2.4 203 非权威信息(Non-Authoritative information) 10.2.5 204 无内容 (No Content) 10.2.6 205 重置内容(Reset Content) 10.2.7 206 部分内容(Partial Content) 10.3 重新定向 3xx. 10.3.1 300 多个选择.(Multiple Choices) 10.3.2 301 永久移动 (Moved Permanently) 10.3.3 302 发现(Found) 10.3.4 303 见其他(See Other) 10.3.5 304 没有被改变(Not Modified) 10.3.6 305 使用代理服务器 (User Proxy) 10.3.7 306没有使用的(unused) 10.3.8 307临时重发(Temporary Redirect) 10.4 客户错误 4xx 10.4.1 400 坏请求(Bad Request) 10.4.2 401 未授权的 (Unauthorized) 10.4.3 402 必需的支付 (Payment Required) 10.4.4 403 禁用 (Forbidden) 10.4.5 404 没有找到(Not Found) 10.4.6 405 不被允许的方法(Method Not Allowed) 10.4.7 406 不接受的 (Not Acceptable) 10.4.8 407 代理服务器授权所需(Proxy Authentication Required) 10.4.9 408 请求超时(Request Timeout) 10.4.10 409 冲突 (Confilict) 10.4.11 410 不存在(gone) 10.4.12 411 必需的长度 (Length Required) 10.4.13 412 先决条件失败 (Precondition Failed) 10.4.14 413 请求实体太大 10.4.15 414 请求URI太长(Request-URI Too Long) 10.4.16 415 不被支持的媒体类型(Unsupported Media Type) 10.4.17 416 请求范围不满足 (Requested Range Not Satisfiable) 10.4.18 417 期望失败 10.5 服务器错误 5xx (Server Error) 10.5.1 500 服务器内部错误 (Internal Server Error) 10.5.2 501 不能实现 (Not Implemented) 10.5.3 502 坏网关 (Bad Gateway) 10.5.4 503 难以获得的服务.(Service Unavailable) 10.5.5 504 网关超时(Gateway Timeout) 10.5.6 505 HTTP版本不支持 (HTTP version Not Supported) 11.入口验证(Access Authentication) 12.内容协商 (Content Negotiation) 12.1 服务器驱动协商(Server-driven Negotiation) 12.2 代理驱动协商 (Agent-driven Negotiation) 12.3 透明协商(Transparent Negotiation) 13 HTTP中的缓存 13.1.1缓存正确性(Cache Correctness) 13.1.2警告信息(Warnings) 13.1.3缓存控制机制 (Cache-control Mechanism) 13.1.4显示的用户代理警告(Explicit User Agent Warnings) 13.1.5规则和警告的例外情况 13.1.6由客户控制的行为(Client-controlled Behavior) 13.2 过期模型 (Expiration Model) 13.2.1 服务器指定模型(Server-Specified Expiratiion) 13.2.2 启发式过期 13.2.3 年龄(Age)计算 13.2.4 过期计算(Expiration Calculations) 13.2.5澄清过期值(Disambiguation Expiration Values) 13.2.6澄清多个响应(Disambiguating Multiple Response) 13.3 验证模型(Validation Model) 13.3.1最后修改日期 (Last-Modified Dates) 13.3.2 实体标签缓存验证器(Entity Tag Cache Validators) 13.3.3 强,弱验证器 (Weak and Strong Validators) 13.3.4 关于何时使用实体标签和最后修改时间的规则 13.3.5非验证条件(Non-validating Conditionls) 13.4 响应的可缓存性(Response Cacheability) 13.5 从缓存里构造响应 13.5.1End-to-end和Hop-by-hop头域 13.5.2不可更改的头域 (Non-modifiable Headers) 13.5.3联合头域(Combining Headers) 13.5.4联合字节范围(Combing Byte Ranges) 13.6 缓存已经协商过的响应(Caching Negotiated Responses) 13.7 共享和非共享缓存 (Shared and Non-Shared Caches) 13.8 错误和不完全的响应缓存行为 13.9 GET 和 HEAD 的副作用(Side Effects of GET and HEAD) 13.10 在更新或删除后的无效性 13.11 强制写通过( Write-Through Mandatory) 13.12 缓存替换 (Cache Replacement) 13.13 历史列表 (History Lists) 14 头域定义 14.1 Accept 14.2 Accept-Charset 14.3 Accept-Encoding 14.4 Accept-Language 14.5 Accept-Range 14.6 Age 14.7 Allow 14.8 Authorization (授权) 14.9 Cache-Control 14.9.1什么是可缓存的 14.9.2什么能被缓存保存 14.9.3对基本过期机制的改进 14.9.4缓存重验证和加载控制(Cache Revalidation and Reload Controls) 14.9.5 No-Transform缓存控制指令 14.9.6缓存控制扩展(Cache control Extendions) 14.10 Connection 14.11 Content-Encoding 14.12 Content-Language 14.13 Content-Length 14.14 Content-Location 14.15 Content-MD5 14.16 Content-Range 14.17 Content-Type 14.18 Date 14.18.1没有时钟的源服务器运作 14.19 ETag 14.20 Expect 14.21 Expires 14.22 From 14.23 Host 14.24 If-Match 14.25 If-Modified-Since 14.26 If-None-Match 14.27 If-Range 14.28 If-Unmodified-Since 14.29 Last-Modified 14.30 Location 14.31 Max-Forwards 14.32 Pragma 14.33 Proxy-Authenticate 14.34 Proxy-Authorization 14.35 Range 14.35.1字节范围 (Byte Ranges) 14.35.2范围请求(Range Retrieval Requests) 14.36 Referer 14.37 Retry-After 14.38 Server 14.39 TE 14.40 Trailer 14.41 Transfer-Encoding 14.42 Upgrade 14.43 User-Agent 14.44 Vary 14.45 Via 14.46 Warning 14.47 WWW-Authenticate 15.安全考虑 (Security Consideration) 15.1 个人信息 (Personal Information) 15.1.1服务器日志信息的滥用 (Abuse of Server Log Information) 15.1.2敏感信息的传输 (Transfer of Sensitive Inforamtion) 15.1.3 URI中敏感信息的编码(Encoding Sensitive Information in URI’s) 15.1.4连接到Accept头域的隐私问题 15.2 基于文件和路径名称的攻击 15.3 DNS欺骗 15.4 Location头域和欺骗 15.5 Content-Disposition的问题 15.6 授权证书和空闲客户端
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值