基础协议知识2

GET和POST的区别

	GET	POST
后退按钮/刷新	无害	数据会被重新提交（浏览器应该告知用户数据会被重新提交）。
书签	可收藏为书签	不可收藏为书签
缓存	能被缓存	不能缓存
编码类型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。
历史	参数保留在浏览器历史中。	参数不会保存在浏览器历史中。
对数据长度的限制	是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	无限制。
对数据类型的限制	只允许 ASCII 字符。	没有限制。也允许二进制数据。
安全性	与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ！	POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。
可见性	数据在 URL 中对所有人都是可见的。	数据不会显示在 URL 中。

 

总结

1、GET获取数据；POST提交数据

2、GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。

3、GET产生一个TCP数据包；POST产生两个TCP数据包。

 

参考链接

https://www.cnblogs.com/logsharing/p/8448446.html

https://baijiahao.baidu.com/s?id=1620934682611653374&wfr=spider&for=pc

https://www.jianshu.com/p/22aad0481886

 

 

 

 

 

 

 

 

HTTP／1.0／1.1／2.0

HTTP1.0

HTTP 协议老的标准是HTTP/1.0，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。但是，这也造成了一些性能上的缺陷，例如，一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的图像标签后，浏览器将根据标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求。显 然，访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应，每次请求和响应都需要建立一个单独的连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性能。当一个网页文件中包含JavaScript文件，CSS文件等内容时，也会出现类似上述的情况。

同时，带宽和延迟也是影响一个网络请求的重要因素。在网络基础建设已经使得带宽得到极大的提升的当下，大部分时候都是延迟在于响应速度。基于此会发现，http1.0被抱怨最多的就是连接无法复用，和head of line blocking这两个问题。理解这两个问题有一个十分重要的前提：客户端是依据域名来向服务器建立连接，一般PC端浏览器会针对单个域名的server同时建立6～8个连接，手机端的连接数则一般控制在4～6个。显然连接数并不是越多越好，资源开销和整体延迟都会随之增大。连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。head of line blocking会导致带宽无法被充分利用，以及后续健康请求被阻塞。

head of line blocking(holb)会导致健康的请求会被不健康的请求影响，而且这种体验的损耗受网络环境影响，出现随机且难以监控。为了解决holb带来的延迟，协议设计者设计了一种新的pipelining机制。pipelining只能适用于http1.1,而且由于使用苛刻，很多浏览器厂商并不支持。

 

HTTP1.1

为了克服HTTP 1.0的这个缺陷，HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。

在http1.1，request和reponse头中都有可能出现一个connection的头，此header的含义是当client和server通信时对于长链接如何进行处理。

在http1.1中，client和server都是默认对方支持长链接的， 如果client使用http1.1协议，但又不希望使用长链接，则需要在header中指明connection的值为close；如果server方也不想支持长链接，则在response中也需要明确说明connection的值为close。不论request还是response的header中包含了值为close的connection，都表明当前正在使用的tcp链接在当天请求处理完毕后会被断掉。以后client再进行新的请求时就必须创建新的tcp链接了。

HTTP 1.1在继承了HTTP 1.0优点的基础上，也克服了HTTP 1.0的性能问题。HTTP 1.1通过增加更多的请求头和响应头来改进和扩充HTTP 1.0的功能。如，HTTP 1.0不支持Host请求头字段，WEB浏览器无法使用主机头名来明确表示要访问服务器上的哪个WEB站点，这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。HTTP/1.0不支持文件断点续传，<code>RANGE:bytes</code>是HTTP/1.1新增内容，HTTP/1.0每次传送文件都是从文件头开始，即0字节处开始。<code>RANGE:bytes=XXXX</code>表示要求服务器从文件XXXX字节处开始传送，这就是我们平时所说的断点续传！

 

HTTP/1.1相较于 HTTP/1.0 协议的区别主要体现在：

1 缓存处理

2 带宽优化及网络连接的使用

3 错误通知的管理

4 消息在网络中的发送

5 互联网地址的维护

6 安全性及完整性

 

HTTP2.0

HTTP/2 （原名HTTP/2.0）即超文本传输协议 2.0，是下一代HTTP协议。是由互联网工程任务组（IETF）的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。HTTP 2.0在2013年8月进行首次合作共事性测试。在开放互联网上HTTP 2.0将只用于https://网址，而 http://网址将继续使用HTTP/1，目的是在开放互联网上增加使用加密技术，以提供强有力的保护去遏制主动攻击。DANE RFC6698允许域名管理员不通过第三方CA自行发行证书。

 

HTTP2.0，相较于HTTP1.x，大幅度的提升了web性能。在与HTTP/1.1完全语义兼容的基础上，进一步减少了网络延迟和传输的安全性。HTTP2.0可以说是SPDY的升级版（基于SPDY设计的），但是依然存在一些不同点：HTTP2.0支持明文传输，而SPDY强制使用HTTPS；HTTP2.0消息头的压缩算法采用HPACK，而非SPDY采用的DEFLATE。

 

HTTP2.0协议的几个特性。

多路复用 (Multiplexing)

多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。在 HTTP/1.1 协议中浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞。这也是为何一些站点会有多个静态资源 CDN 域名的原因之一，拿 Twitter 为例，http://twimg.com，目的就是变相的解决浏览器针对同一域名的请求限制阻塞问题。而 HTTP/2 的多路复用(Multiplexing) 则允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。因此 HTTP/2 可以很容易的去实现多流并行而不用依赖建立多个 TCP 连接，HTTP/2 把 HTTP 协议通信的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。并行地在同一个 TCP 连接上双向交换消息。

二进制分帧

HTTP/2在 应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层中， HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码 ，其中 HTTP1.x 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。

HTTP/2 通信都在一个连接上完成，这个连接可以承载任意数量的双向数据流。在过去， HTTP 性能优化的关键并不在于高带宽，而是低延迟。TCP 连接会随着时间进行自我调谐，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度。这种调谐则被称为 TCP 慢启动。由于这种原因，让原本就具有突发性和短时性的 HTTP 连接变的十分低效。HTTP/2 通过让所有数据流共用同一个连接，可以更有效地使用 TCP 连接，让高带宽也能真正的服务于 HTTP 的性能提升。

这种单连接多资源的方式，减少服务端的链接压力,内存占用更少,连接吞吐量更大；而且由于 TCP 连接的减少而使网络拥塞状况得以改善，同时慢启动时间的减少,使拥塞和丢包恢复速度更快。

首部压缩（Header Compression）

HTTP/1.1并不支持 HTTP 首部压缩，为此 SPDY 和 HTTP/2 应运而生， SPDY 使用的是通用的DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。

服务端推送（Server Push）

服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。Server Push 让 HTTP1.x 时代使用内嵌资源的优化手段变得没有意义；如果一个请求是由你的主页发起的，服务器很可能会响应主页内容、logo 以及样式表，因为它知道客户端会用到这些东西。这相当于在一个 HTML 文档内集合了所有的资源，不过与之相比，服务器推送还有一个很大的优势：可以缓存！也让在遵循同源的情况下，不同页面之间可以共享缓存资源成为可能。

 

参考文献

https://www.jianshu.com/p/52d86558ca57

https://www.jianshu.com/p/1ad439279974

 

 

cookie/session机制

cookie与session应用于互联网中的一项基本技术——会话（用户与客户端的交互）跟踪技术，用来跟踪用户的整个会话。简单来说，cookie是通过在客户端记录信息确定用户身份的，而session则通过在服务器端记录信息确定用户身份。

cookie 定义

cookie是服务器传给客户端的体积很小的纯文本文件。客户端请求服务器，如果服务器需要记录该用户状态，就向客户端浏览器发一个cookie。客户端浏览器会把cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该cookie一同提交给服务器。服务器检查该cookie，以此来辨认用户状态。

cookie属性

cookie的主要属性包括：名字，值，过期时间，路径和域：

路径与域一起构成cookie的作用范围。

过期时间：对于会话cookie，如果不设置过期时间，表示这个cookie的生命期为浏览器的会话期间，关闭浏览器窗口，cookie就消失了，会话cookie一般保存在内存里。对于持久cookie，设置了过期时间，浏览器会把cookie保存在硬盘上，存储在硬盘上的cookie会在不同的浏览器进程间共享。

名字：就是给cookie起一个名字。

值：cookie中记录的信息内容。

应用场景

判断注册用户是否已经登录网站：用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录流程。

根据用户的爱好定制内容：网站创建包含用户浏览内容的cookies，在用户下次访问时，网站根据用户的情况对显示的内容进行调整，将用户感兴趣的内容放在前列。

实现永久登录：如果用户是在自己家的电脑上上网，登录时就可以记住他的登录信息，下次访问时不需要再次登录，直接访问即可。

实现自动登录：当用户注册网站后，就会收到一个惟一用户ID的cookie。用户再次连接时，这个用户ID会自动返回，服务器对它进行检查，确定它是否是注册用户且选择了自动登录，从而使用户无需给出明确的用户名和密码，就可以访问服务器上的资源。

使用cookie记录各个用户的访问计数：获取cookie数组中专门用于统计用户访问次数的cookie的值，将值加1并将最新cookie输出。

使用cookie记住用户名与用户密码。用户勾选了“自动登录”，就把用户名和密码的信息放到cookie中。同时可设置有效期。

用cookie实现新手大礼包等弹窗功能。同理，将新手大礼包弹窗逻辑写入到cookie中，并设置相应的有效期。比如在有效期内只弹出一次该弹窗，超过有效期登录后再次弹出弹窗。

 

 

 

 

 

 

session 定义

session是另一种记录客户状态的机制，不同的是cookie保存在客户端浏览器中，而session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是session。客户端浏览器再次访问时只需要从该session中查找该客户的状态就可以了。session相当于程序在服务器上建立的一份用户的档案，用户来访的时候只需要查询用户档案表就可以了。

session的生命周期与有效期

为了获得更高的存取速度，服务器一般把session放在内存里。每个用户都会有一个独立的session。如果session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。session的使用虽然比cookie方便，但是过多的session存储在服务器内存中，会对服务器造成压力。因此，session里的信息应该尽量精简。

session在用户第一次访问服务器的时候自动创建。session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该session。

由于有越来越多的用户访问服务器，因此session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的session从内存中删除。这个时间就是session的超时时间。如果超过了超时时间没访问过服务器，session就自动失效了。

session与cookie

虽然session保存在服务器，但是它的正常运行仍然需要客户端浏览器的支持。这是因为session需要使用cookie作为识别标志。HTTP协议是无状态的，session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为SESSIONID的cookie，它的值为该Session的id。Session依据该cookie来识别是否为同一用户。

对于不支持cookie的手机浏览器，有另一种解决方案：URL地址重写。URL地址重写的原理是将该用户session的id信息重写到URL地址中，服务器能够解析重写后的URL获取session的id。这样即使客户端不支持cookie，也可以使用session来记录用户状态。

应用场景

通过session累计用户数据。例如，一个未登录用户访问了京东网站，这个时候京东对其下发了一个 cookie，假设cookie的名字叫做abc，那这条记录就是 abc＝001，同时京东的后台也生成了一个 session id， 它的值也为 001， 001 这个客户在 2 点、 3 点、 4 点分别添加了三件商品到购物车，这样后台也记录了 session id 为 001的用户的购物车里面已经有三件商品，并且只要每次客户端 cookie 带上来的值里面包含session id，后台都能够展示相应的数据，如果这个时候，在浏览器里面清空 cookie，cookie 数据消失之后，后台和客户端无法建立对应关系，购物车的数据就会失效了。

通过session实现单点登录。一个用户帐号成功登录后，在该次session还未失效之前，不能在其他机器上登录同一个帐号。登录后将用户信息保存到session中，如果此时在另外一台机器上一个相同的帐号请求登录，通过遍历（遍历的意思就是将所有session都查看一遍）Web服务器中所有session并判断其中是否包含同样的用户信息，如果有，在另一台机器上是不能登录该帐号的。

 

总结

1）cookie数据存放在客户的浏览器上，session数据放在服务器上。

2）cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。

3）session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。

4）单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5）可以考虑将登陆信息等重要信息存放为session，其他信息如果需要保留，可以放在cookie中。

 

HTML5 WebStorage

WebStorage是HTML5中本地存储的解决方案之一，在HTML5的WebStorage概念引入之前除去IE User Data、Flash Cookie、Google Gears等看名字就不靠谱的解决方案，浏览器兼容的本地存储方案只有使用cookie。有同学可能会问，既然有了cookie本地存储，为什么还要引入WebStorage的概念？

 

Cookie缺陷

cookie的缺陷是非常明显的

1. 数据大小：作为存储容器，cookie的大小限制在4KB左右这是非常坑爹的，尤其对于现在复杂的业务逻辑需求，4KB的容量除了存储一些配置字段还简单单值信息，对于绝大部分开发者来说真的不知指望什么了。

2. 安全性问题：由于在HTTP请求中的cookie是明文传递的（HTTPS不是），带来的安全性问题还是很大的。

3. 网络负担：我们知道cookie会被附加在每个HTTP请求中，在HttpRequest 和HttpResponse的header中都是要被传输的，所以无形中增加了一些不必要的流量损失。

使用HTML5可以在本地存储用户的浏览数据。早些时候,本地存储使用的是 cookie。但是Web 存储需要更加的安全与快速，这些数据不会被保存在服务器上，但是这些数据只用于用户请求网站数据上。它也可以存储大量的数据，而不影响网站的性能。数据以 键/值 对存在, web网页的数据只允许该网页访问使用。

Web Storage的目的是为了克服由cookie带来的一些限制，当数据需要被严格控制在客户端上时，无须持续地将数据发回服务器。Web Storage的两个主要目标是：

提供一种在cookie之外存储会话数据的途径。

提供一种存储大量可以跨会话存在的数据的机制。

Web Storage又分为两种： sessionStorage 和localStorage ，即这两个是Storage的一个实例。从字面意思就可以很清楚的看出来，sessionStorage将数据保存在session中，浏览器关闭也就没了；而localStorage则一直将数据保存在客户端本地。其API提供的方法有以下几种：

setItem (key, value) ——  保存数据，以键值对的方式储存信息。

getItem (key) ——  获取数据，将键值传入，即可获取到对应的value值。

removeItem (key) ——  删除单个数据，根据键值移除对应的信息。

clear () ——  删除所有的数据。

key (index) —— 获取某个索引的key

 

localStorage

localStorage的生命周期是永久性的。假若使用localStorage存储数据，即使关闭浏览器，也不会让数据消失，除非主动的去删除数据，使用的方法如上所示。localStorage有length属性，可以查看其有多少条记录的数据。

 

sessionStorage

sessionStorage 的生命周期是在浏览器关闭前。也就是说，在整个浏览器未关闭前，其数据一直都是存在的。sessionStorage也有length属性，其基本的判断和使用方法和localStorage的使用是一致的。需要注意的有以下几点：

1、页面刷新不会消除数据;

2、只有在当前页面打开的链接，才可以访sessionStorage的数据；

3、使用window.open打开页面和改变localtion.href方式都可以获取到sessionStorage内部的数据;

 

web storage的特点

优点

每个域Chrome，Firefox和Opera是5M，IE是10M。

请求中不会携带数据

不足

目前所有的浏览器中都会把localStorage的值类型限定为string类型，这个在对我们日常比较常见的JSON对象类型需要一些转换

localStorage在浏览器的隐私模式下面是不可读取的

localStorage本质上是对字符串的读取，如果存储内容多的话会消耗内存空间，会导致页面变卡

localStorage不能被爬虫抓取到

 

常考题

一、请你谈谈cookie的弊端

cookie虽然在持久保持客户端数据提供了方便，分担了服务器存储的负担，但还是有很多局限。

1、IE6或更低版本最多20个cookie；

2、IE7和之后的版本最后可以有50个cookie；

3、Firefox最多50个cookie；

4、chrome和Safari没有做硬性限制；

5、IE和Opera 会清理近期最少使用的cookie，Firefox会随机清理cookie；

6、cookie的最大大约为4096字节，为了兼容性，一般不能超过4095字节。

 

IE 提供了一种存储可以持久化用户数据，叫做userdata，从IE5.0就开始支持。每个数据最多128K，每个域名下最多1M。这个持久化数据放在缓存中，如果缓存没有清理，那么会一直存在。

 

优点：极高的扩展性和可用性

1）通过良好的编程，控制保存在cookie中的session对象的大小；

2）通过加密和安全传输技术（SSL），减少cookie被破解的可能性；

3）在cookie中不存放敏感数据，即使被盗也不会有重大损失；

4）控制cookie的生命期，使之不会永远有效。偷盗者很可能拿到一个过期的cookie。

缺点：

1）Cookie`数量和长度的限制。每个domain最多只能有20条cookie，每个cookie长度不能超过4KB，否则会被截掉。在当今新的浏览器和客户端设备版本中，支持 8192 字节的 Cookie 大小已愈发常见。

2）用户配置为禁用。有些用户禁用了浏览器或客户端设备接收 Cookie 的能力，因此限制了这一功能；

3）由于在HTTP请求中的cookie是明文传递的，潜在的安全风险，Cookie 可能会被篡改；

4）有些状态不可能保存在客户端；

5）cookie会被附加在每个HTTP请求中，所以无形中增加了流量。

6）cookie一般不可跨域使用；

7）没有封装好的setCookie和getCookie方法，需要开发者自省封装。

 

二、cookie 和session 的区别：

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗

考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能

考虑到减轻服务器性能方面，应当使用COOKIE。

4、单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

5、所以个人建议：

将登陆信息等重要信息存放为SESSION

其他信息如果需要保留，可以放在COOKIE中

 

三、web storage和cookie的区别

1.Cookie的大小是受限的

2. 每次你请求一个新的页面的时候Cookie都会被发送过去，这样无形中浪费了带宽

3. cookie还需要指定作用域，不可以跨域调用

4. Web Storage拥有setItem,getItem等方法，cookie需要前端开发者自己封装setCookie，getCookie

5. Cookie的作用是与服务器进行交互，作为HTTP规范的一部分而存在 ，而Web Storage仅仅是为了在本地“存储”数据而生

6. IE7、IE6中的UserData通过简单的代码封装可以统一到所有的浏览器都支持web storage

 

四、请描述一下 cookies与sessionStorage和localstorage区别

相同点：都存储在客户端

不同点：

1.存储大小

cookie数据大小不能超过4k。

sessionStorage和localStorage 虽然也有存储大小的限制，但比cookie  大得多，可以达到5M或更大。

2. 有效时间

localStorage存储持久数据，浏览器关闭后数据不丢失除非主动删除数据；

sessionStorage  数据在当前浏览器窗口关闭后自动删除。

cookie 设置的cookie过期时间之前一直有效，即使窗口或浏览器关闭

3. 数据与服务器之间的交互方式

cookie的数据会自动的传递到服务器，服务器端也可以写cookie到客户端

sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存。

 

五、Session将产生的session_id放在Cookie里面，如果用户把Cookie所禁用了，那么是不是Session的功能也无法使用了？

先回答，禁用了Cookie功能，Session功能还是可以正常使用的，只是我们可以通过其他方式来传递session_id，例如通过类似get请求方式一样，将session_id附加到URL地址的后面进行传输，或者通过Post请求方式。从而一样可以让服务端和客户端进行状态确认。

 

六、在开发中，session是公认的比Cookie安全。为什么？

第一点，先说下为什么Cookie不安全：一：在我过去的面试经历中，有一位技术经理告诉过我，他可以通过将Cookie的文件拷贝到另一台计算机，另一个客户端上进行对相同网站的登录，可以这样欺骗服务端，实现登录。是的，这就是由于Cookie是存储在客户端浏览器上的，导致用户可以直接进行操作，导致了安全性的降低。

真正的Cookie是存储在客户端的硬盘上的一个文本文件，如果两者的安全性一样，那么就可以不使用Session，这样就可以减轻服务器的负载了。

通过Cookie来获取session_id，得有两个条件：必须要有人首次进行登录之后，或者重启session才会有。第二个条件就是session_id必须是要有效的，所以必须保证session_id是最后一次登录所生成的，session在生命周期以内，且解密已经加密的session_id在短时间很难受实现。。

对于使得Session失效的方法有多种：1.重启tomcat，2.session生命周期结束（可以手动配置），3.可以调用session.invalidate();方法进行回收。

参考资料

https://www.jianshu.com/p/26e1e9fa7089

https://www.cnblogs.com/dolphinX/p/3348469.html

https://www.cnblogs.com/liuwei0824/p/7699632.html

https://www.jianshu.com/p/b5efddc433f5

https://blog.csdn.net/weixin_41950078/article/details/84278233

进程与线程

 

进程

进程=程序+执行。当把一个程序从磁盘里加载到内存中，cpu去运算和处理这个进程。

（跑起来的程序就是进程）

 

从三个维度来看进程模型

 

 

为什么会引入进程模型？

最开始的操作系统是单道编程，一个程序处理完，再处理下一个程序，

缺点：1.响应时间慢（客户体验差）2.cpu利用率非常低

举例：假设一个进程，20%需要cpu做运算，80%在做I/O（发生I/O事件时，Cpu是闲置的）=》

cpu的利用率是20%。如果是单道编程模型，cpu的利用率就是20%。

多道编程下：两个进程：1-0.8*0.8=36% 三个进程的：1-0.8*0.8*0.8=48%

总结：进入进程模型，目的就是为了满足多道编程，多道编程的目的就是为了提高cpu的利用

率。随着进程数量的增多，cpu的利用率逐步提高。

 

进程产生和消亡的事件

产生	消亡
1.操作系统会产生服务进程 2.父进程创建子进程 3.用户请求创建一个进程	1.进程的所有运算都处理完之后，自行退出 2.进程在运行过程中产生错误或异常而强行退出 3.一个进程被其他进程所杀死而退出

 

进程的状态

执行态 | 挂起态

状态	说明
执行态	一个进程正在被cpu运算
挂起态	对于挂起态，要讨论的是什么原因导致的挂起 1.一个进程由于发生了某些阻塞操作，比如发生I/O事件，那进程会被挂起 2.一个进程由于执行了很长时间，主动挂起，让其他进程得以处理。 3.用户主动将进程进行挂起，比如sleep操作 总结：针对第一类和第三类挂起的进程，即使把cpu给这个进程，cpu也处理不了， 我们把这样的挂起进程称之为：阻塞态进程 针对第 二类进程，称之为：就绪态进程

所以细分，进程的状态：执行态|就绪态|阻塞态（计算机在做进程调度时，是不会调度和查看阻塞态进程的）

 

进程的状态转变

执行-就绪

执行-阻塞

就绪-执行

就绪-阻塞（就绪-执行-阻塞）

阻塞-执行（阻塞-就绪-执行）

阻塞-就绪

线程模型

一个进程必须有一个线程，也可以有多个线程。

举例：比如拿onenote写笔记，这个笔记进程会监听打字，此外，每隔3分钟自动存盘（3s存

盘）。

总结：进入线程模型，目的就是为了让进程可以同时做多件事。（线程是进程的分身）

此外，引入线程模型后，cpu的最小执行单位就变成了线程。

最后的总结：进程相当于资源组织单位，线程是cpu最小执行单位。

调度算法

1.FCFS First come First server 先来先服务调度算法=》处理先来的线程，线程处理完之后，再处

理下个线程。

2.时间片轮转调度算法。这个算法的出现解决了FCFS算法的问题，降低了响应时间，提高了

cpu利用率。但是这个算法可能存在的缺陷是：短任务处于饥饿状态，

 

3.短任务优先调度算法。优先去完成短任务。这个算法的局限性:可能会导致长任务时间处于

饥饿状态。

4.优先级调度算法。为线程分配优先级，优先级高的优先被处理。这个算法的局限性:优先级

低的线程长时间处于饥饿状态。

5.混合调度算法。这个算法把之前算法的有点进行结合，然后做线程调度

 

线程与进程的区别

a. 一个程序至少有一个进程，一个进程至少有一个线程

b. 线程的划分尺度小于进程，使得多线程程序的并发性高

c. 进程在执行过程中拥有独立的内存单元，而多个线程共享内存，从而极大地提高了程序的运行效率

d. 每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行，必须依存在应用程序中，由应用程序提供多个线程执行控制

e. 多线程的意义在于一个应用程序中，有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用，来实现进程的调度和管理以及资源分配