「开位」你所应该知道的HTTP——基础篇

前言

本人学习HTTP相关知识的总结，力求以最简单和高效的语言说明问题，让你们快速掌握知识点。
本章家主要介绍HTTP协议的基础，重点放在对cookie的讲解。
本人能力有限，若有不正确之处请批评指正。

概述

HTTP全称Hypertext Transfer Protocol，即超文本传输协议。
它是一种属于应用层的通讯协议，容许将超文本标记语言（HTML）文档从Web服务器传送到客户端的浏览器。
HTTP字面意义上就是为了HTML的传输而发明的网络协议，但进过不断的完善、改进和发展后，它已经再也不局限于此，好比如今css、js、图片也是经过这个协议传输的。所以HTTP已经成为了Web领域一种通用的传输协议。

发展简史

• 1990年10月
  万维网之父Tim Berners-Lee最先提出了HTTP协议
• 1991年
  HTTP/0.9诞生（Tim的文章）
• 1994年
  成立W3C组织
• 1996年5月
  HTTP/1.0发布（RFC1945）
• 1997年1月
  HTTP/1.1发布（初版RFC2068，第二版RFC2616）
• 2000年5月
  HTTPS发布（RFC2818）
• 2015年5月
  HTTP/2.0（取代SPDY协议）发布（RFC7540）
• 将来
  QUIC协议，或HTTP/3.0

特色

1. 支持客户/服务器模式
   由客户端向服务器发出请求，服务器端响应请求，并进行相应服务。
2. 简单快速
   客户向服务器请求服务时，只需传送请求方法和路径。因为HTTP协议简单、使得HTTP服务器的程序规模小，于是通讯速度很快。
3. 灵活
   HTTP容许传输任意类型的数据类型。传输的类型由Content-Type头部标识加以标记。
4. 无链接（限HTTP/1.1以前）
   限制每次TCP链接只处理一个请求。服务器处理完客户的请求，并应答后，即断开链接。采用这种方式能够节省服务器资源。HTTP/1.1以后加入的keep-alive机制必定程度上打破了这一限制。
5. 无状态
   协议对于事务处理没有记忆能力。这样的设计让服务器能够省略不少上下文的维护工做，也有利于不稳定的网络环境。但缺乏状态意味着若是后续处理须要前面的信息，则它必须重传，这样可能致使每次链接传送的数据量增大。

报文结构

请求部分

1. 请求行（Request line）
   位与第一行；分为Method（请求方法）、Path-to-resource（请求URI）、Http/Version-number（HTTP协议及版本）三部分。
2. 请求报文头（Request headers）
   从第二行开始至第一个空行结束；向服务器传递附加信息，形式是<key>:<value>。
3. 请求报文体（Request body）
   从第一个空行以后的都是正文；可选；能够自定义格式的文本，好比json格式、表单格式、二进制数据。

响应部份

1. 响应行（Response line）
   位与第一行；分为Http/Version-number（HTTP协议及版本）、Statuscode（状态码）、message（状态描述）三部分；
2. 响应报文头（Response headers）
   从第二行开始至第一个空行结束；向客户端传递附加信息，形式是<key>:<value>。
3. 响应报文体（Response body）
   从第一个空行以后的都是正文；可选；能够自定义格式的文本，好比json格式、表单格式、二进制数据。

报文头

HTTP协议的报文头大致能够分为四类：通用报文头、请求报文头、响应报文头和实体报文头（描述报文体）。
在HTTP/1.1里一共规范了47种报文头字段。
各类报文定义参见：报文列表

请求方法

请求方法使用在请求行中，是客户端告诉服务器该执行什么样的数据操做的标记，但也仅仅只是标记做用，并无严格意义上限制服务器的行为。
可以严格遵循这套标准的服务，好比RESTful架构，有利于语义化并提供客户端必定的自主性，但在非标准实现的服务器上，你甚至能够用一个POST方法涵盖GET、POST、PUT、DELETE操做。

• GET
  用来请求访问已被URI标识的资源，会把请求的数据挂在URL中；对用户隐私不友好；请求的字符长度有限制（IE最短，只支持2083）。
• POST
  通常用来传输实体的主体，目的不是获取响应主体内容；把数据放在报文体里传送。
• PUT
  和POST同样，用来提交数据，不一样的是，PUT是幂等的，POST不是幂等的。
• HEAD
  和GET差很少，只不过是用于获取报头的，能够用来验证超连接的有效性。
• DELETE
  请求服务器删除指定资源，和PUT同样没有验证机制，存在安全隐患。
• TRACE
  回显服务器收到请求，用于测试或诊断。
• CONNECT
  开启一个C端和所请求资源之间的双向沟通的通道，好比代理服务器proxy来访问网站。
• OPTION
  用来查询针对请求URI指定的资源支持的方法。

等幂性：若是一个方法或功能执行一次或者屡次，结果是同样的，那么就说这个方法或功能是等幂的。
例如，设置某个用户的性别为男性，这个方法不管执行一次仍是屡次，它的结果都是相同的。因此，该方法具备幂等性。
例如，某个帐户充值100元，这个方法执行一次和执行屡次的结果是不相同的。因此，该方法不具备幂等性。

响应状态码

用以表示网页服务器超文本传输协议响应状态的3位数字代码。按首字母可分为如下五大类：

• 1xx：表示消息。表明请求已被接受，须要继续处理；只包含状态行，几乎不用。
• 2xx：表示成功。表明请求已被服务器接收、理解、接受。
• 3xx：重定向。表明须要客户端采起进一步操做才能完成请求，后续的请求地址在本次的响应location域中指明。
• 4xx：请求错误。表明客户端看起来可能发生了错误。
• 5xx：表示服务器错误。

完整列表请参考：状态码列表

cookie

概述

前面讲到HTTP协议的特色时，提到其“无状态”的特性，但实际使用中须要登陆状态的场景是十分广泛的，为了解决这个问题就有了cookie机制。
cookie其实是服务器保存在客户端上的一小段的文本信息。以键值对的形式保存，并由客户端维护其有效期。服务器经过响应报文头set-cookie进行设置。当客户端再次请求该源时，会在请求报文头里将有效的cookie提交给服务器。
cookie遵循同源策略。cookie这种保存并自动回传必定数据的特性，使基于无状态的HTTP协议记录稳定的状态信息成为了可能。

不知道同源策略是啥能够看个人另外一篇文章的第一部分：传送门。

格式

响应报文头

set-cookie是响应报文头，形如：

set-cookie: <key>=<value>; Expires=<date>; Secure; HttpOnly

key为属性名，value为值，一个set-cookie设置一个key，如需设置多个key，只须要同时返回多个set-cookie，例子中Expires、Secure、HttpOnly为可选值。全部可选属性以下：

属性名	说明文字
Expires	超时时间点，默认是session，即关闭浏览器失效。
Max-Age	失效前的秒数。优先级高于expires。
Domain	可使用这个cookie的域，二级域名可指定为一级，一级只能指定为一级。
Path	可使用这个cookie的路径。
Secure	限制该cookie只经过https传递。
HttpOnly	限制该cookie只由服务器读写，不能被js获取到。

请求报文头

cookie是请求报文头，形如：

cookie: <key>=<value>; <key>=<value>...

key为属性名，value为值，会一次返回该源下的全部有效key，以分号为分割。这个结果与在浏览器执行document.cookie获取到的值相同。

cookie与session

session是服务器记录客户状态的机制。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。客户端再次访问时只须要从该session中查找该用户的状态。
通常session与cookie配合使用，构成会话跟踪技术，即session-cookie机制。

session-cookie机制过程以下：
服务器生成session的id（即sessionid）后，就将它经过set-cookie传递到客户端，客户端保存这个sessionid，下次请求经过cookie回传到服务器，服务器便可经过sessionid查询到用户的session，进而得到用户状态。

示意图：