session

任何框架要用首先要到pom依赖 。。。 在shiro.xml配置文件配置shiro相关信息 因为securityManager需要realm package com . ssq . realm ; import com . ssq . pojo . User ; import com . ssq . service . RoleService ; import com . ssq . service . UserService ; import org . apache . shiro . authc . * ; import org . apache . shiro . authz . AuthorizationInfo ; import org . apache . shiro . authz . SimpleAuthorizationInfo ; import org . apache . shiro . realm . AuthorizingRealm ; import org . apache . shiro . subject . PrincipalCollection ; import org . apache . shiro . util . ByteSource ; import org . springframework . beans . factory .

1. GTP是什么 GTP：GPRS Tunnel Protocol，GPRS隧道传输协议。 GTP是一组基于IP的高层协议，位于TCP/IP，UDP/IP协议之上。 GTP-U是其中一种GTP。 2. GTP-U GTP-U用来传输S1和X2用户面数据。 GTP-U既可以基于IPv4/UDP，也可以基于IPv6/UDP。 隧道端点之间的数据通过IP地址和UDP端口号进行路由。 3. TEID Tunnel endpoint ID，隧道端点标识符。 由接收端生成，供发送端使用，通过s1/x2信令交换。 s1接口：数据上传TEID由S-GW分配，数据下传TEID由eNodeB分配。SAE建立和响应，初始上下文建立和响应。 X2接口：由目标eNodeB分配。 LTE中S1-GTP-U的分配和作用 LTE的架构和接口如下： 在这里eNodeb通过S1-u口与SGW建立起数据的连接。​采用的协议是GTP-U协议，其连接要素为eNodeb的和SGW的。​ 这一对连接要素是MME在SGW上为UE创建Session时创建的。创建的时机有Attach，或者换SGW切换。 从下面的Attach流程来看：​ Attach的部分流程 从上面第12步到16步，可以看到MME在与SGW交互，为UE创建Session分配ip和teid。​ 下面用一次实际环境抓包的消息内容，来举例teid的分配： 1

session 一个session就是一系列某用户和服务器间的通讯，http协议是无状态的，服务器没有能力分辨出不同的用户，但通过cookie和session可以达到记录状态的目的。一个session的建立是从一个用户向服务器发第一个请求开始，而以用户显式结束session超时为结束。 session的作用域也比较大，共享request域。 服务器是如何为实现一个session为一个用户浏览器服务的？ //使用request对象的getSession()获取session，如果session不存在，则创建一个 HttpSession session = request.getSession(); //获取session id String sessionid = session.getID(); if(session.isNew){ response.getWrite().print("session创建成功，session的id为"+sessionid); //保存会话数据（作为域对象） session.setAttribute("name","xiaowang"); session.getAttribute("name"); }esle{ response.getWrite().print("服务器已存在session，session的id为"+sessionid); } 来源

JSP是什么？ JSP全称Java Server Page，直译就是“运行在服务器端的页面”。我们可以直接在JSP文件里写HTML代码，使用上把它当做HTML文件。而且JSP中HTML/CSS/JS等的写法和HTML文件中的写法是一模一样的。但它毕竟不是HTML，而且本质差了十万八千里。因为我们还可以把Java代码内嵌在JSP页面中，很方便地把动态数据渲染成静态页面。这一点，HTML打死都做不到。 当有人请求JSP时，服务器内部会经历一次动态资源（JSP）到静态资源（HTML）的转化，服务器会自动帮我们把JSP中的HTML片段和数据拼接成静态资源响应给浏览器。也就是说JSP是运行在服务器端，但最终发给客户端的都已经是转换好的HTML静态页面（在响应体里）。 即：JSP = HTML + Java片段（各种标签本质上还是Java片段） JSP本质就是一个Servlet。 EB容器接收到以.jsp为扩展名的URL的访问请求时，它将把该请求交给JSP引擎去处理。Tomcat中的JSP引擎就是一个Servlet程序，它负责解释和执行JSP页面。 每个JSP 页面在第一次被访问时，JSP引擎将它翻译成一个Servlet源程序，接着再把这个Servlet源程序编译成Servlet的class类文件

第一方面：开发速度的对比 就开发速度而言，Hibernate的真正掌握要比Mybatis来得难些。Mybatis框架相对简单很容易上手，但也相对简陋些。个人觉得要用好Mybatis还是首先要先理解好Hibernate。 比起两者的开发速度，不仅仅要考虑到两者的特性及性能，更要根据项目需求去考虑究竟哪一个更适合项目开发，比如：一个项目中用到的复杂查询基本没有，就是简单的增删改查，这样选择hibernate效率就很快了，因为基本的sql语句已经被封装好了，根本不需要你去写sql语句，这就节省了大量的时间，但是对于一个大型项目，复杂语句较多，这样再去选择hibernate就不是一个太好的选择，选择 mybatis 就会加快许多，而且语句的管理也比较方便。 第二方面：开发工作量的对比 Hibernate和MyBatis都有相应的代码生成工具。可以生成简单基本的DAO层方法。针对高级查询，Mybatis需要手动编写SQL语句，以及ResultMap。而Hibernate有良好的映射机制，开发者无需关心SQL的生成与结果映射，可以更专注于业务流程。 第三方面：sql优化方面 Hibernate的查询会将表中的所有字段查询出来，这一点会有性能消耗。Hibernate也可以自己写SQL来指定需要查询的字段，但这样就破坏了Hibernate开发的简洁性。而Mybatis的SQL是手动编写的

一，cookie技术 Cookie是由服务器端生成，发送给浏览器，浏览器会将Cookie的key/value保存到某个目录下的文本文件内，下次请求同一网站时就发送该Cookie给服务器前提是浏览器设置为启用cookie。 1，服务器端向客户端发送一个Cookie 1）创建Cookie： Cookie cookie = new Cookie(String cookieName,String cookieValue); 示例： Cookie cookie = new Cookie("username"，"zhangsan"); 那么该cookie会以响应头的形式发送给客户端： 注意：Cookie不能存储中文 2）设置Cookie在客户端的持久化时间： void setMaxAge(int seconds) cookie.setMaxAge(int seconds); ---时间秒 注意：如果不设置持久化时间，cookie会存储在浏览器的内存中，浏览器关闭 cookie信息销毁（会话级别的cookie），如果设置持久化时间，cookie信息会被持久化到浏览器的磁盘文件里 示例： cookie.setMaxAge(10*60); 设置cookie信息在浏览器的磁盘文件中存储的时间是10分钟，过期浏览器 自动删除该cookie信息 3）设置Cookie的携带路径： void setPath

一、单服务器架构 小猿公司创立初期准备搭建一个电商网站销售公司产品，因为公司创业初期用户量不大而且着急上线，在资金有限的情况下公司购买了一台服务器，将小猿团队开发的网站放到服务器上这便算是正式上线了。 二、服务器集群 项目上线没多久就暴露了很多问题： 单点问题（服务器宕机将导致整个系统不可用） 处理效率问题，单台服务器可以接收的请求量十分有限，用户量大的情况下响应速度大幅下降，甚至出现内存溢出。 遇到了以上问题就必须对服务架构进行调整了，通过商量小猿团队决定增加服务器数量，这样可以已解决单服务器请求压力过大的问题，同时就算有部分服务器宕机了对外也能正常提供服务。 集群 引入了几个新问题： 每个服务器的ip地址不一样，如何让用户知道到底要访问哪一个？ session问题，之前用户登录信息，购物车信息等等都是存在服务器的内存中，服务器集群后如何保证每个服务器共享session数据。 三、负载均衡 现在需要解决的就是让每个服务器处理的请求数能竟可能的均衡一些，比如轮循机制。这就是 负载均衡 。 负载均衡器的主要工作就是接受用户请求，并且根据一定的算法将请求分发给不同的服务器，架构调整后形成了下图的模式 （集群带来session的处理问题一般可以采用redis或者其他缓存服务器进行处理，这里不展开讨论了） 四、分布式 随着小猿公司的业务越来越负载，团队的成员也越来越多

本篇开始写「单点登录与权限管理」系列的第一部分：单点登录与权限管理本质，这部分主要介绍相关的知识概念、抽象的处理过程、常见的实现框架。通过这部分的介绍，能够对单点登录与权限管理有整体上的了解，对其相关概念、处理流程、常见实现有个基本的认识。 本篇文章介绍下session和cookie，它是登录实现的基础，主要从下面几个方面介绍： session和cookie基本概念 session的生命周期 cookie的作用域 cookie的跨域问题会在后续文章单独介绍。 基本概念 大部分系统都需要识别用户的身份，有些功能只有特定的用户能使用，有些功能需要根据用户身份显示不同的内容，一般使用唯一编号标识用户的身份。 就像我们的×××，×××号是每个人唯一的，根据所在的省市区、出生年月、性别等规则生成，我们去政府机构办事时，都需要带着×××，他们通过×××验证我们的身份。 session和cookie主要用来识别登录者身份的，默认通过JSESSIONID唯一编号进行验证。session是在服务端保存的一个数据结构，用来跟踪用户的状态，也可以保存用户相关的一些数据，可以保存在内存、缓存、数据库等存储结构中。cookie是客户端保存用户信息的一种机制。 servlet session javax.servlet.http包中是session的主要API接口，主要有以下几种接口： HttpSession

强烈推荐使用Python内置库secrets 1. 利用MD5 import time from hashlib import md5 session = md5 ( str ( time . time ( ) ) . encode ( 'utf-8' ) ) session = session . hexdigest ( ) print ( session ) 结果：利用时间戳产生的MD5，如0026fcb876ff6bed4b391df819240c6f 耗时：54.6 µs ± 554 ns 缺点：可暴力破解，高并发时重复率高 2. 利用SHA1 import os from hashlib import sha1 session = sha1 ( str ( time . time ( ) ) . encode ( 'utf-8' ) ) session = session . hexdigest ( ) print ( session ) 结果：利用时间戳产生的SHA1，如568ecfe658cc7ce16fd91ac2e03e4afe62f6b4f2 耗时：55.6 µs ± 1.33 µs 缺点：可暴力破解，高并发时重复率高 3. 利用UUID from uuid import uuid4 session = uuid4 ( ) print ( session )

0. 引子，我们为什么要cookie和session 因为http请求是无状态的（不能记录用户的登录状态等），所以需要某种机制来保存用户的登录状态等信息，在下次访问web服务的时候，不用再次校验是否登录等状态，session机制和cookie机制分别是在服务器端和浏览器端的解决方案。 1.关于cookie 1.1 什么是cookie cookie，原意饼干。用来在浏览器端存储用户的状态信息，然后在访问后端的时候将这部分信息带回到后端。 cookie的内容主要包括：名字，值，过期时间，路径和域 1.2 cookie的分类 会话cookie 不设置过期时间的cookie 保存在浏览器的内存中，关闭浏览器，cookie便被销毁。（常常被用作session） 普通cookie 设置了过期时间 保存在硬盘上 1.3怎么应用 发起请求时：浏览器检查所有存储的cookie，如果某个cookie所声明的作用范围（由路径和域决定）大于等于将要请求的资源所在的位置，则把该cookie附在请求资源的HTTP请求头上发送给服务器。 处理请求时：在服务器端， 一般会对请求头中带的cookie信息做检查（比如说登录检查），如果检查通过，才能进行实际的业务处理。 如果校验不通过，例如没有找到cookie或者cookie信息不正确（可能是伪造），跳转让其登录，然后登录完成之后，在响应中返回cookie信息