http协定开展历程一览
这里我只是对一些知识停止简便的整理，利便本人懂得记忆，还有许多不完美的地方，更多细节，需要查看书籍或者其他文章
http和谈的开展历程
HTTP 是基于 TCP/IP 和谈的利用层和谈。它不触及数据包（packet）传输，主要规定了客户端和效劳器之间的通讯格局，默许使用80端口。
http/0.9
1991年公布，只要一个命令GET，和谈规定，效劳器只能回应HTML格局的字符串，不克不及回应别的格局。
http/1.0
1996年5月公布，HTTP/1.0 版本公布，内容大大增添，第一，任何格局的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。这为互联网的大开展奠定了根基。除了GET命令，还引入了POST命令和HEAD命令，丰硕了阅读器与效劳器的互动手段。
HTTP恳求和回应的格局也变了。除了数据部分，每次通讯都必需包罗头信息（HTTP header），用来描写一些元数据。
其他的新增功效还包罗状态码（status code）、多字符集支撑、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。
**缺陷：**
每个TCP连接只能发送一个恳求。发送数据完毕，连接就关闭，假如还要恳求其他资源，就必需再创建一个连接。
TCP连接的创建成本很高，由于需要客户端和效劳器三次握手，并且开端时发送速率较慢（slow start）。所以，HTTP 1.0版本的机能比力差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。为理解决这个问题，有些阅读器在恳求时，用
列表项目
了一个非标准的Connection字段。
Connection: keep-alive
一个可以复用的TCP连接就创立了，直到客户端或效劳器主动关闭连接。但是，这不是标准字段，不一样实现的行动大概不一致，因此不是基本的解决方法。
http/1.1
1997年1月公布，HTTP/1.1 版本公布，只比 1.0 版本晚了半年。它进一步完美了 HTTP 和谈，不断用到了20年后的今天，直到此刻还是最流行的版本。
1.1 版的最大转变，就是引入了耐久连接（persistent connection），即TCP连接默许不关闭，可以被多个恳求复用，不消声明Connection: keep-alive。
客户端和效劳器发明对方一段时间没有活动，就可以主动关闭连接。不外，标准的做法是，客户端在最后一个恳求时，发送Connection: close，明白要求效劳器关闭TCP连接。
1.1版还新增了很多动词办法：PUT、PATCH、HEAD、 OPTIONS、DELETE。
**缺陷**
虽然1.1版同意复用TCP连接，但是统一个TCP连接里面，所有的数据通讯是按次序停止的。效劳器只要处置完一个回应，才会停止下一个回应。如果前面的回应特殊慢，后面就会有很多恳求排队等着。这称为"队头堵塞"（Head-of-line blocking）。
为了不这个问题，只要两种办法：
一是减少恳求数；
二是同时多开耐久连接。这致使了许多的网页优化技巧，比方合并足本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。假如HTTP和谈设计得更好一些，这些额外的工作是可以幸免的。
SPDY
2009年，谷歌公示了自行研发的 SPDY 和谈，主要解决 HTTP/1.1 效力不高的问题。这个和谈在Chrome阅读器上证明可行今后，就被当作 HTTP/2 的根基，主要特性都在 HTTP/2 之中得到继承。
HTTP/2
2015年，HTTP/2 公布。它不叫 HTTP/2.0，是由于标准委员会不打算再公布子版本了，下一个新版本将是 HTTP/3。
HTTP/1.1 版的头信息必定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制和谈。
二进制和谈的一个好处是，可以定义额外的帧。HTTP/2 定义了近十种帧，为未来的高级利用打好了根基。假如使用文本实现这种功效，解析数据将会变得非常费事，二进制解析则利便得多。
HTTP/2 复用TCP连接，在一个连接里，客户端和阅读器都可以同时发送多个恳求或回应，并且不消依照次序一一对应，这样就幸免了"队头堵塞"。
HTTPS
HTTPS是HTTP和谈的平安版本，HTTP和谈的数据传输是明文的，是不平安的，HTTPS使用了SSL/TLS和谈停止了加密处置。
http和谈的特点
无状态——每次HTTP恳求都是独立的，任何两个恳求之间没有什么必定的联络。但是在实际利用傍边并不是完全这样的，引入了Cookie和Session机制来关联恳求。
无连接的——每次恳求完成之后马上断开连接
单向的利用层和谈——通讯恳求只能由客户端发起，效劳端对恳求做出应对处置。
屡次恳求—— 在客户端恳求网页时多数状况下并不是一次恳求就能成功的，效劳端第一是响应HTML页面，然后阅读器收到响应之后发明HTML页面还援用了其他的资源，例如，CSS，JS文件，图片等等，还会主动发送HTTP恳求这些需要的资源。
此刻的HTTP版本支撑管道机制（即在统一个TCP连接里面，客户端可以同时发送多个恳求），可以同时恳求和响应多个恳求，大大提高了效力。
http报文构造
恳求行
url —— Request URL
恳求办法 —— Request Method
状态码 —— Status Code
效劳器地址 —— Remote Address
在跨域回绝时，大概是method为options，状态码为404/405等（当然，实际上大概的组合有许多）的
**常用状态码：**
200——表白该恳求被成功地完成，所恳求的资源发送回客户端
304——自从上次恳求后，恳求的网页未修改正，请客户端使用当地缓存
400——客户端恳求有错（比如可以是平安模块拦截）
401——恳求未经授权
403——制止拜访（比如可以是未登录时制止）
404——资源未寻到
500——效劳器内部错误
503——效劳不成用
...
**HTTP恳求办法**
在HTTP1.1版本中支撑GET、POST等近10种办法.
通用首部字段
HTTP Cookie
本质上cookies就是http的一个扩展。有两个http头部是专门负责设定乃至发送cookie的,它们离别是Set-Cookie乃至Cookie。
HTTP Cookie（也叫Web Cookie或阅读器Cookie）是效劳器发送到会员阅读器并留存在当地的一小块数据，它会在阅读器下次向统一效劳器再发起恳求时被携带并发送到效劳器上。平常，它用于告知效劳端两个恳求可否来自统一阅读器，如保持会员的登录状态。Cookie使基于无状态的HTTP和谈记载不乱的状态信息成为了大概。
Cookie主要用于以下三个方面：
会话状态治理（如会员登录状态、购物车、游戏分数或其它需要记载的信息）
个性化设定（如会员自定义设定、主题等）
阅读器行动跟踪（如跟踪剖析会员行动等）
Cookie曾一度用于客户端数据的储备，因当时并没有其它适宜的储备方法而作为独一的储备手段，但此刻随着现代阅读器开端支撑许许多多的储备方式，Cookie慢慢被裁汰。由于效劳器指定Cookie后，阅读器的每次恳求都会携带Cookie数据，会带来额外的机能开销（特别是在移动环境下）。新的阅读器API已经同意开发者直接将数据储备到当地，如使用 Web storage API （当地储备和会话储备）或 IndexedDB 。
创立cookie
效劳器收到HTTP恳求时，效劳器可以在响应头里面增加一个Set-Cookie选项。阅读器收到响应后平常会留存下Cookie，之后对该效劳器每一次恳求中都通过Cookie恳求头部将Cookie信息发送给效劳器。别的，Cookie的过期时间、域、途径、有效期、适用站点都可以按照需要来指定。
nodejs中效劳端设定cookie的办法
request.setHeader('Set-Cookie', ['type=ninja', 'language=javascript']);cookie是留存在客户端中，依照客户端中储备的位置，可分为内存cookie和硬盘cookie。
内存cookie
cookie的保存时间是整个会话期间的话，阅读器会将cookie留存在内存中，阅读器关闭时就会主动清除这个cookie
硬盘cookie
就是cookie留存在客户端的硬盘中，阅读器关闭的话，该cookie也不会被清除，下次翻开阅读器拜访对应网站时，这个cookie就会主动再次发送到效劳器端。
cookie不成跨域
许多网站都会使用Cookie。例如：Google会向客户端颁布Cookie，Baidu也会向客户端颁布Cookie。那阅读器拜访Google会不会也携带上Baidu颁布的Cookie呢？或者Google能不克不及修改Baidu颁布的Cookie呢？
案可否定的。Cookie具有不成跨域名性。按照Cookie标准，阅读器拜访Google只会携带Google的Cookie，而不会携带Baidu的Cookie。Google也只能操纵Google的Cookie，而不克不及操纵baidu的Cookie。
Cookie在客户端是由阅读器来治理的。阅读器能够包管Google只会操纵Google的Cookie而不会操纵Baidu的Cookie，从而包管会员的隐私平安。阅读器推断一个网站可否能操纵另一个网站Cookie的根据是域名。Google与Baidu的域名不一样，因此Google不克不及操纵Baidu的Cookie。
统一个1级域名下的两个二级域名如www.helloweenvsfei.com和images.helloweenvsfei.com也不克不及交互使用Cookie，由于二者的域名并不严厉雷同。假如想所有helloweenvsfei.com名下的二级域名都可以使用该Cookie，需要设定Cookie的domain参数，例如：
Cookie cookie = new Cookie("time","20080808"); // 创建Cookie
cookie.setDomain(".helloweenvsfei.com"); // 设定域名
cookie.setPath("/"); // 设定途径
cookie.setMaxAge(Integer.MAX_VALUE); // 设定有效期
response.addCookie(cookie); // 输出到客户端cookie的有效期
Cookie的maxAge决议着Cookie的有效期，单位为秒（Second）。Cookie中通过getMaxAge()办法与setMaxAge(int maxAge)办法来读写maxAge属性。 假如maxAge属性为正数，则表示该Cookie会在maxAge秒之后主动失效。阅读器会将maxAge为正数的Cookie耐久化，即写到对应的Cookie文件中。不管客户关闭了阅读器还是电脑，只要还在maxAge秒此前，登录网站时该Cookie依然有效。
假如maxAge为负数，则表示该Cookie仅在本阅读器窗口乃至本窗口翻开的子窗口内有效，关闭窗口后该Cookie即失效。maxAge为负数的Cookie，为暂时性Cookie，不会被耐久化，不会被写到Cookie文件中。Cookie信息留存在阅读器内存中，因此关闭阅读器该Cookie就消逝了。
留意：从客户端读取Cookie时，包罗maxAge在内的其他属性都是不成读的，也不会被提交。阅读器提交Cookie时只会提交name与value属性。maxAge属性只被阅读器用来推断Cookie可否过期。
Cookie的平安属性
HTTP和谈不仅是无状态的，并且是不平安的。使用HTTP和谈的数据不经过任何加密就直接在网络上传播，有被截获的大概。使用HTTP和谈传输很秘密的内容是一种隐患。假如不但愿Cookie在HTTP等非平安和谈中传输，可以设定Cookie的secure属性为true。阅读器只会在HTTPS和SSL等平安和谈中传输此类Cookie。下面的代码设定secure属性为true：
Cookie cookie = new Cookie("time", "20080808"); // 创建Cookie
cookie.setSecure(true); // 设定平安属性
response.addCookie(cookie); // 输出到客户端提醒：secure属性并不克不及对Cookie内容加密，因此不克不及包管绝对的平安性。假如需要高平安性，需要在程序中对Cookie内容加密、解密，以防泄密。
http session
session和cookie一样，都是用来记载http状态的一种机制，但不一样的是cookie存在于客户端，所携带的大小收到限制，而session则存在于效劳端，储备的大小不受限制。
当程序需要为某个客户端的恳求创立一个session的时候，效劳器第一检查这个客户端的恳求里可否已包括了一个session标识- 称为session id，假如已包括一个session id则说明之前已经为此客户端创立过session，效劳器就依照session id把这个session检索出来使用（假如检索不到，大概会创建一个），假如客户端恳求不包括session id，则为此客户端创立一个session并且生成一个与此session相关联的session id，session id的值应当是一个既不会反复，又不容易被寻到纪律以仿造的字符串，这个session id将被在本次响应中返回给客户端留存。 留存这个session id的方式可以采纳cookie，这样在交互历程中阅读器可以主动的依照规则把这个标识发挥给效劳器。一样这个cookie的名字都是相似于SEEESIONID。
平常session的创立需要依靠cookie，但cookie可以被人为的制止，需要有其他的机制以便在cookie被制止的时候能够把session id 传递回效劳器，可以把session id直接附加在URL途径的后面
留意：在议论session机制的时候，常常听到这样一种曲解“只要关闭阅读器，session就消逝了”。其实可以想象一下会员卡的例子，除非顾客主动对店家提出销卡，不然店家绝对不会轻易删除顾客的材料。对session来说也是一样的，除非程序通知效劳器删除一个session，不然效劳器会不断保存，程序一样都是在会员做log off的时候发个指令去删除session。
然而阅读器从来不会主动在关闭此前通知效劳器它将要关闭，因此效劳器基本不会有时机知道阅读器已经关闭，之所以会有这种错觉，是大部分session机制都使用会话cookie来留存session id，而关闭阅读器后这个session id就消逝了，再次连接效劳器时也就没法寻到本来的session。
假如效劳器设定的cookie被留存到硬盘上，或者使用某种手段改写阅读器发出的HTTP恳求头，把本来的session id发送给效劳器，则再次翻开阅读器依然能够寻到本来的session。
以上就是http和谈开展历程一览的具体内容，更多请关注百分百源码网其它相关文章！
