nginx如何解决跨域问题，Java的前景如何？
Java在互联网中的应用十分的广泛，采用JAVA语言开发的网站也越来越多，在众多的编程语言排行榜中，Java仍然高居榜首，在国内的软件开发企业中，Java语言的使用比例也排名第一，企业的需求量还是很大的，薪资和附加值在各个行业中也都是最高的；
系统的学习一下会更好，少走弯路，可以规避掉自学中的很多问题和麻烦，学的更加系统；以前学习Java的时候是在“ 如鹏网 ”上面学习的，有网络的地方就可以学习，根据自己的时间来灵活安排学习进度，把空余的时间充分的利用起来，也有更多的时间来练习项目，夯实基础；
有问题随时提问，老师实时在线答疑，每个章节的后面都有详细的练习题和面试口才题，需要以录音的方式进行提交，直到通过为止，为以后的面试做充分的准备，毕业前，老师会专门讲解“如何写简历、如何投简历、如何面试、如何谈薪资避免贱卖”，并对每位同学的就业全程进行指导。
有新的课程更新了，也是可以继续免费申请了来学习的，有技术大牛亲自授课，口碑不错，基本上都是慕名而去的，具体的可以到如鹏网官网上去了解一下，有详细的课程体系，可以参考一下；
第一部分：Java语言入门阶段
第二部分：Java高级技术
第三部分：web前端
第四部分：Javaweb编程（核心阶段）
第五部分：企业框架
第六部分：项目阶段
第七部分：企业专题
session共享有什么方案么？
1. 网站交互体验升级作为网友的我们，每天都会使用浏览器来逛各种网站，来满足日常的工作生活需求。
现在的交互体验还是很丝滑的，但早期并非如此，而是一锤子买卖。1.1 无状态的 HTTP 协议无状态的 HTTP 协议是什么鬼？HTTP 无状态协议，是指协议对于业务处理没有记忆能力，之前做了啥完全记不住。每次请求都是完全独立互不影响的，没有任何上下文信息。缺少状态意味着如果后续处理需要前面的信息，则它必须重传关键信息，这样可能导致每次连接传送的数据量增大。如果大家没明白，可以想一下《夏洛特烦恼》里面的桥段：大概明白了吧，假如一直用这种原生无状态的 HTTP 协议，我们每换一个页面可能就得重新登录一次，那还玩个球。所以必须要解决 HTTP 协议的无状态，提升网站的交互体验，否则星辰大海是去不了的。1.2 解决之道整个事情交互的双方只有客户端和服务端，所以必然要在这两个当事者身上下手。客户端来买单客户端每次请求时把自己必要的信息封装发送给服务端，服务端查收处理一下就行。服务端来买单客户端第一次请求之后，服务端就开始做记录，然后客户端在后续请求中只需要将最基本最少的信息发过来就行，不需要太多信息了。2. Cookie方案Cookie 总是保存在客户端中。按在客户端中的存储位置，可分为内存 Cookie 和硬盘Cookie。内存 Cookie 由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的。硬盘 Cookie 保存在硬盘里，有一个过期时间。除非用户手工清理或到了过期时间，硬盘Cookie不会被删除，其存在时间是长期的。2.1 Cookie 定义和作用HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据。它会在浏览器下次向同一服务器再发起请求时，被携带并发送到服务器上。通常 Cookie 用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的HTTP协议记录稳定的状态信息成为了可能。Cookie 主要用于以下三个方面：会话状态管理（如用户登录状态、购物车等其它需要记录的信息）个性化设置（如用户自定义设置、主题等）浏览器行为跟踪（如跟踪分析用户行为等）2.2 服务端创建 Cookie当服务器收到 HTTP 请求时，服务器可以在响应头里面添加一个 Set-Cookie 选项。浏览器收到响应后通常会保存下 Cookie，之后对该服务器每一次请求中都通过 Cookie 请求头部将 Cookie 信息发送给服务器。另外，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。2.3 B/S 的 Cookie 交互服务器使用 Set-Cookie 响应头部向用户浏览器发送 Cookie信息。一个简单的 Cookie 可能像这样：Set-Cookie: <cookie名>=<cookie值> HTTP/1.0 200 OKContent-type: text/htmlSet-Cookie: yummy_cookie=chocoSet-Cookie: tasty_cookie=strawberry
客户端对该服务器发起的每一次新请求，浏览器都会将之前保存的Cookie信息通过 Cookie 请求头部再发送给服务器。GET /sample_page.html HTTP/1.1Host: www.example.orgCookie: yummy_cookie=choco; tasty_cookie=strawberry
我来访问下淘宝网，抓个包看看这个真实的过程：2.4 存在的问题Cookie 常用来标记用户或授权会话，被浏览器发出之后可能被劫持，被用于非法行为，可能导致授权用户的会话受到攻击，因此存在安全问题。还有一种情况就是跨站请求伪造 CSRF，简单来说 比如你在登录银行网站的同时，登录了一个钓鱼网站，在钓鱼网站进行某些操作时可能会获取银行网站相关的Cookie信息，向银行网站发起转账等非法行为。跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的 Web 应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了 Web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。不过这种情况有很多解决方法，特别对于银行这类金融性质的站点，用户的任何敏感操作都需要确认，并且敏感信息的 Cookie 只能拥有较短的生命周期。同时 Cookie 有容量和数量的限制，每次都要发送很多信息带来额外的流量消耗、复杂的行为 Cookie 无法满足要求。特别注意：以上存在的问题只是 Cookie 被用于实现交互状态时存在的问题，但并不是说 Cookie 本身的问题。试想一下：菜刀可以用来做菜，也可以被用来从事某些暴力行为，你能说菜刀应该被废除吗？3. Session 方案3.1 Session 机制的概念如果说 Cookie 是客户端行为，那么 Session 就是服务端行为。Cookie 机制在最初和服务端完成交互后，保持状态所需的信息都将存储在客户端，后续直接读取发送给服务端进行交互。Session 代表服务器与浏览器的一次会话过程，并且完全由服务端掌控，实现分配ID、会话信息存储、会话检索等功能。Session 机制将用户的所有活动信息、上下文信息、登录信息等都存储在服务端，只是生成一个唯一标识 ID 发送给客户端，后续的交互将没有重复的用户信息传输，取而代之的是唯一标识 ID，暂且称之为 Session-ID 吧。3.2 简单的交互流程当客户端第一次请求 session 对象时候，服务器会为客户端创建一个 session，并将通过特殊算法算出一个 session 的 ID，用来标识该 session 对象；当浏览器下次请求别的资源的时候，浏览器会将 sessionID 放置到请求头中，服务器接收到请求后解析得到 sessionID，服务器找到该 id 的 session 来确定请求方的身份和一些上下文信息。3.3 Session 的实现方式首先明确一点，Session 和 Cookie 没有直接的关系。可以认为 Cookie 只是实现 Session 机制的一种方法途径而已，没有 Cookie 还可以用别的方法。Session和Cookie的关系就像加班和加班费的关系，看似关系很密切，实际上没啥关系。Session 的实现主要两种方式：Cookie 与 URL 重写，而 Cookie 是首选方式。因为各种现代浏览器都默认开通 Cookie 功能，但是每种浏览器也都有允许 Cookie 失效的设置，因此对于 Session 机制来说还需要一个备胎。将会话标识号以参数形式附加在超链接的URL地址后面的技术称为 URL 重写原始 URL：http://taobao.com/getitem?name=baymax&action=buy
重写后的 URL:http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy
3.4 存在的问题由于 Session 信息是存储在服务端的，因此如果用户量很大的场景，Session 信息占用的空间就不容忽视。对于大型网站必然是集群化&分布式的服务器配置。如果 Session 信息是存储在本地的，那么由于负载均衡的作用，原来请求机器 A 并且存储了 Session 信息，下一次请求可能到了机器 B，此时机器 B 上并没有 Session 信息。这种情况下要么在 B 机器重复创建造成浪费，要么引入高可用的 Session 集群方案，引入 Session 代理实现信息共享，要么实现定制化哈希到集群 A，这样做其实就有些复杂了4. Token 方案Token 是令牌的意思，由服务端生成并发放给客户端，是一种具有时效性的验证身份的手段。Token 避免了 Session 机制带来的海量信息存储问题，也避免了 Cookie 机制的一些安全性问题，在现代移动互联网场景、跨域访问等场景有广泛的用途。4.1 简单的交互流程客户端将用户的账号和密码提交给服务器；服务器对其进行校验，通过则生成一个 token 值返回给客户端，作为后续的请求交互身份令牌；客户端拿到服务端返回的 token 值后，可将其保存在本地，以后每次请求服务器时都携带该 token，提交给服务器进行身份校验；服务器接收到请求后，解析关键信息，再根据相同的加密算法、密钥、用户参数生成 sign 与客户端的 sign 进行对比，一致则通过，否则拒绝服务；验证通过之后，服务端就可以根据该 Token 中的 uid 获取对应的用户信息，进行业务请求的响应。4.2 Token 的设计思想以 JSON Web Token（JWT）为例，Token主要由三部分组成：Header 头部信息：记录了使用的加密算法信息；Payload 净荷信息：记录了用户信息和过期时间等；Signature 签名信息：根据 header 中的加密算法和 payload 中的用户信息以及密钥key来生成，是服务端验证服务端的重要依据。header 和 payload 的信息不做加密，只做一般的 base64 编码。服务端收到 token 后剥离出 header 和 payload 获取算法、用户、过期时间等信息，然后根据自己的加密密钥来生成 sign，并与客户端传来的 sign 进行一致性对比，来确定客户端的身份合法性。这样就实现了用 CPU 加解密的时间换取存储空间，同时服务端密钥的重要性就显而易见，一旦泄露整个机制就崩塌了，这个时候就需要考虑 HTTPS 了。4.3 Token 方案的特点Token 可以跨站共享，实现单点登录；Token 机制无需太多存储空间。Token 包含了用户的信息，只需在客户端存储状态信息即可，对于服务端的扩展性很好；Token 机制的安全性依赖于服务端加密算法和密钥的安全性；Token 机制也不是万金油。5. 总结Cookie、Session、Token 这三者是不同发展阶段的产物，并且各有优缺点，三者也没有明显的对立关系，反而常常结伴出现，这也是容易被混淆的原因。Cookie 侧重于信息的存储，主要是客户端行为。Session 和 Token 侧重于身份验证，主要是服务端行为。三者方案在很多场景都还有生命力，了解场景才能选择合适的方案。本文分享自华为云社区《Cookie、Session、Token 背后的故事-云社区-华为云》，作者： 龙哥手记。
前后端分离一定要用nginx吗？
不一定，但目前nginx是首选，因为对外来说同域名应用。nginx作用是实现转发，避免跨域。实际如果内网使用无特别要求也可以业务直接互通
为什么只用get和post？
我有一个老朋友，我们叫他熊猫。发际线及将触碰到后脑勺，大框金丝眼镜也掩盖不住那黝黑的眼圈，显得格外的“程序员”；穿着也非常“不拘一格”，上半身是衬衣西服，下半身是牛仔裤配拖鞋。
我和熊猫的感情很好，毕业后他去了上海而我开始北漂，但每次过节回老家我俩都会和朋友们一起吃饭，这次回家过年也不例外，我们朋友几个去了枣庄出名的小板凳酱骨头，饭后他给我们聊了聊4年前来这家公司的面试经历，据说跟面试官有着一番精彩的博弈；我们听得津津有味。
以下是熊猫和面试官刘经理的对话。
面试官：小李啊，你们常用的HTTP请求方法都有哪些啊？
熊猫：是这样的，HTTP/1.1协议中共定义了八种方法，有时也叫“动作”，来表明Request-URL指定的资源不同的操作方式
在HTTP1.0中，定义了三种请求方法： GET, POST 和 HEAD方法。在HTTP1.1中，新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法但我们常用的一般就是GET和POST请求。
面试官：嗯，那你说说GET和POST请求都有哪些区别呢？（果然进套了，看你小子有几斤几两）
熊猫：这个。。。没有太关注过，以我的理解，大概有这么几种区别吧:
GET请求在URL中传送的参数是有长度限制的，而POST没有。GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。而POST数据不会显示在URL中。是放在Request body中。对参数的数据类型，GET只接受ASCII字符，而POST没有限制。GET请求参数会被完整保留在浏览器历史记录里；相反，POST请求参数也不会被浏览器保留。GET请求只能进行url编码（application/x-www-form-urlencoded），而POST支持多种编码方式。GET请求会被浏览器主动缓存，而POST不会，除非手动设置。GET在浏览器回退时是无害的，而POST会再次提交请求。
面试官:（没关注过，那你还背的一条不差。跟我搁这儿装B呢？看我怎么教育你。）
面试官:那Get请求有Request body么？如果有的话参数可以像Post请求一样放在里面么？
熊猫：（吼吼，看来有机会把我昨天精心准备的东西给他扯半小时了[手动挠头] 让开，我要装波B了）
熊猫：其实吧，GET和POST在本质上没有区别，都是HTTP协议中的两种发送请求的方法。而HTTP呢，是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
万维网：简称WWW，是World Wide Web的简称，也称为Web、3W等
HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。
GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。
举个例子吧：
TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。
但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。
为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，包括GET, POST, PUT等等，
HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。
如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里（request body中）。
当然，你也可以在用GET的时往车厢内偷偷藏点货物，但这并不不光彩；也可以在POST的时候在车顶上也放一些数据，也会让人觉得傻乎乎的。
HTTP只是个行为准则，而GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
面试官：（哎呀，这小子还真的了解这块儿啊，看来是我误会他了，难道遇到了大佬？）
面试官：小李，你说的不错，那你刚才说的URL中传送参数的长度限制在Get和Post中都是怎么样的呢？
熊猫：其实在Web中啊，还有另一个重要的角色：运输公司。
不同的浏览器Client端（发起http请求）和服务器server端（接受http请求）就是不同的运输公司。
虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。
业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。
超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略。
所以，虽然GET可以带request body，却不能保证一定能被接收到。
示例：
我之前处理过一个bug，用户反应查询没有响应，同事查了日志后才发现有几个参数都是undefined，很奇怪，最后发现原来是因为Get请求第一个查询参数太长了，导致URL后面的部分服务器无法接收 ，后来把请求改成post，将参数放在request body后就可以了。
面试官：（看来理论确实是掌握的不错，让我考考他实际应用）面试官：那GET 方法参数写法是固定的吗？熊猫：在约定中，我们的参数是写在 ? 后面，用 & 分割。如下：
http://ip:port/project/getUserInfo?username=chenhhaha&age=26&sex=2
我们知道，解析报文的过程是通过获取 TCP 数据，用正则等工具从数据中获取 Header 和 Body，从而提取参数。
比如header请求头中添加token，来验证用户是否登录等权限问题。
也就是说，我们可以自己约定参数的写法，只要服务端能够解释出来就行，万变不离其宗。
面试官：那么说来，是不是POST 方法比 GET 方法更安全呢？
熊猫：有人说POST 比 GET 安全，因为数据在地址栏上不可见。
然而，从传输的角度来说，他们都是不安全的，因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。
其实，要想安全传输，就只有加密，也就是 HTTPS。
面试官：嗯，不错小李，看来你对HTTP协议这块儿还是有一定了解的，那么你知道Get、Post请求发送的数据包有什么不同吗？
熊猫：（看来这面试官是非要是把我问倒才满意啊？可惜可惜。看我套路他一波）
熊猫： 实不相瞒，我上家公司加班比较多，昨天刚签完离职，贵公司是我面得第一家公司，所以准备的不充分，这样吧，我大致谈谈我的理解吧，不对的地方您见谅。
面试官：没关系，按你的理解聊聊就行。（这小子没准备就说成这样，我的好好考虑一下，别错失了先机，失去一个能为公司“加班”的人才）
熊猫： 嗯嗯，是这样的，GET请求时产生一个TCP数据包；POST请求时产生两个TCP数据包。
GET：浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；POST：浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 OK（返回数据）。就像是GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“老铁，我等下要送一批货来，你们准备接收一下哈”，然后再回头把货送过去。
因为POST需要两步，理论上时间上消耗的要多一点，看起来GET比POST更有效。但并不是，后来发现原来是个坑。在我看来：
GET与POST都有自己的语义，不能随便混用。据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。我去年用Chrome浏览器测试发现也是只发送一次，所以我认为Get、POST性能差可以人为忽略。
学习技术的朋友们就到此为止了，感觉学到东西的记得帮忙点个赞哦，么么哒。
面试官：小李，你说的很不错，你等一等啊；
五分钟后，面试官拿着一杯饮料进来。。。。
面试官：小李啊，你尝尝这咖啡味道如何？（自古套路得人心，学好了）
熊猫喝了一口，竖起大拇指说到：刘经理，这是正宗的卡布奇诺啊，我平时就喜欢喝，可惜太贵了。。
咦？我进来之前没有看到你们这有咖啡店呀，这是？
面试官嘴角上翘，微微一笑，露出了洁白的两颗大门牙：小李，我看你简历说你爱喝咖啡，巧了，我们公司有专门的水吧，福利之一就是是每天免费一杯咖啡或饮料。以后你可以经常喝了。
面试官：（这个福利，其实是因为我们公司加班多才提出的。别问，问我也不会说~~）
熊猫：刘经理意思是，我面试过了是么，太好了！
熊猫：对了水吧每天几点下班呐？跟开发一个点儿么？（不会是因为经常加班才免费喝咖啡吧，我得试探试探）
面试官：（这问题我听了无数次了，看我滴水不漏的模糊作答 ---- 真·老油子）
面试官：哈哈是啊，水吧一直都是按点下班，咱们公司如果有人加班的话，可以自己去水吧做着喝就行，加班时间都是免费的。
面试官：小李，你这儿没问题的话，我看下周一就入职吧。
熊猫：（听他话的意思公司应该只是偶尔加班啊，这简直让我无法拒绝啊！咦，总感觉不太对。。）熊猫：好的刘经理，那咱们下周见。
前端如何在访问后端时避免跨域访问？
前后端分离实现了技术上更大的专一性，并且赋予了前后数据的灵活性！公司现在沿用的阿里系前后端分离，姑且分享下！
前后端分离之前的时代，MVC框架大行其道，通常是前端(后台亲切称呼为写静态页面的)开发HTML页面，包括CSS等，然后由后端开发人员统一进行动态数据绑定，这样前端的能力没有体现出来，而后端也对改样式，调布局不胜其烦，而且前后端耦合容易引发相互污染，项目笨重等缺点，这时候分离是最好的选择！
原始的MVC模型图示:
读写分离就是将原来后端的框架MVC分为MC＋V，后端controller只需要控制流程的流转，权限认证，业务逻辑等，model层为业务代码与数据层的连接，整个View层全部作为前端项目的形式拆分，单独部署在不同的服务节点上，实现分离！
分离之前View与controller的数据传输只需要通过转发或者重定向，将数据传递到页面，使用特定的EL表达式进行数据接收与显示，分离之后两个项目通常在不同的服务器中，数据的传输涉及到网络通信，所以需要在满足一定的传输协议的基础上进行动态数据的处理！
前后端分离怎么做的呢？
①，后端:后端设计好数据结构后，根据需求提供一套接口文档，内容包括遵循http协议的接口暴露地址，入参，返回对象形式，然后开发好相应的功能接口进行对外服务！（后端框架还是沿袭之前的spring，springboot，mybatis等等）
②，前端:前端则需要把前端代码部署在node.js上，node.js相当于js版本的JVM，是基于google的V8引擎开发的，专门提供给js代码解释环境的一套组件，node.js使用了异步事件驱动，非阻塞的处理模型，能支持大量的并发连接，前段专注于页面渲染和动态数据显示。
③，前后端交互:后端通过一定协议(http，https等)暴露服务，前端相应的进行调用即可，但是因为浏览器具有同源策略，如果是其他域名的脚本通常不会执行，也就是说发生了跨域，怎么实现通信呢？我们才用的是反向代理的方式，通过nginx配置一个映射地址，比如浏览器需要的同源地址为http://123.com，好的没问题，我给你这么访问，在访问某个接口(比如a/b/get)nginx中我通过配置映射将http://123.com/a/b/get映射为http://234.com/a/b/get(后端)实际的暴露地址，实现了数据的获取！
这样的一个架构，在用户看来是完全透明的，实现了整个功能的内聚，前后分离让前后端的开发人员更加专注的维护自己的代码，大大提升了开发人员的效率，如果你在开发过程中有疑惑，欢迎私信，更多的技术分享，敬请关注。。。
