「开位」你所应该知道的HTTP——基础篇
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
特点
- 支持客户/服务器模式
由客户端向服务器发出请求，服务器端响应请求，并进行相应服务。 - 简单快速
客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单、使得HTTP服务器的程序规模小，因而通信速度很快。 - 灵活
HTTP允许传输任意类型的数据类型。传输的类型由Content-Type头部标识加以标记。 - 无连接（限HTTP/1.0之前）
限制每次TCP连接只处理一个请求。服务器处理完客户的请求，并应答后，即断开连接。采用这种方式可以节省服务器资源。但随着网页的复杂度增大，这一限制反而降低了性能，HTTP/1.0之后加入的keep-alive机制一定程度上打破了这一限制。 - 无状态
协议对于事务处理没有记忆能力。这样的设计让服务器可以省略很多上下文的维护工作，也有利于不稳定的网络环境。但缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
报文结构
请求部分
- 请求行（Request line）
位与第一行；分为Method（请求方法）、Path-to-resource（请求URI）、Http/Version-number（HTTP协议及版本）三部分。 - 请求报文头（Request headers）
从第二行开始至第一个空行结束；向服务器传递附加信息，形式是:。 - 请求报文体（Request body）
从第一个空行之后的都是正文；可选；可以自定义格式的文本，比如json格式、表单格式、二进制数据。
响应部份
- 响应行（Response line）
位与第一行；分为Http/Version-number（HTTP协议及版本）、Statuscode（状态码）、message（状态描述）三部分； - 响应报文头（Response headers）
从第二行开始至第一个空行结束；向客户端传递附加信息，形式是:。 - 响应报文体（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为可选值。所有可选属性如下：
请求报文头
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，进而获得用户状态。
示意图：
URI、URL与URN
URI（Uniform Resource Identifier）
统一资源标志符，一个紧凑的字符串用来标示抽象或物理资源。
URL（Uniform Resource Locator）
统一资源定位符，URI的子集，除了确定一个资源，还提供一种定位该资源的主要访问机制。
URN（Uniform Resource Name）
统一资源名称，URI的子集，定义某事物的身份，不关心其访问方式与位置。
示意图：（来自维基百科）
例子：辨析https://segmentfault.com/a/1190000022295229.html#intro
https是访问方式；segmentfault.com/a/1190000022295229.html是存放位置；#intro是资源
URL即https://segmentfault.com/a/1190000022295229.html
URN即segmentfault.com/a/1190000022295229.html#intro
两者都是URI
后记
想要了解更多，敬请关注哦
记得留下你的赞哦