计算机网络——应用层知识点汇总_应用层与网络服务知识重点-CSDN博客

本文链接：https://blog.csdn.net/qq_36263268/article/details/110644930

1.Cookie和Session

Cookie 和 Session都是⽤来跟踪浏览器⽤户身份的会话⽅式，但是两者的应⽤场景不太⼀样。
Cookie ⼀般⽤来保存⽤户信息⽐如：

我们在 Cookie 中保存已经登录过的⽤户信息，下次访问⽹站的时候⻚⾯可以⾃动帮你登录的⼀些基本信息给填了；
⼀般的⽹站都会有保持登录也就是说下次你再访问⽹站的时候就不需要重新登录了，这是因为⽤户登录的时候我们可以存放了⼀个 Token 在 Cookie中，下次登录的时候只需要根据 Token 值来查找⽤户即可(为了安全考虑，重新登录⼀般要将 Token重写)；

Session 的主要作⽤就是通过服务端记录⽤户的状态例如用户的个性配置。典型的场景是购物⻋，当你要添加商品到购物⻋的时候，系统不知道是哪个⽤户操作的，因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的 Session 之后就可以标识这个⽤户并且跟踪这个⽤户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。单个cookie在客户端的限制是4k。

Cookie 存储在客户端中，⽽Session存储在服务器上，相对来说 Session 安全性更⾼。如果要在Cookie 中存储⼀些敏感信息，不要直接写⼊ Cookie 中，最好能将 Cookie 信息加密然后使⽤到的时候再去服务器端解密。

session认证的问题

建立的用户数量增长之后，session数量也会变多，那样就会增加开销；
session是保存在内存中的，这样，对于分布式的应用就会存在很多限制均衡负载的问题。
因为是基于cookie来进行用户识别的，如果cookies被截获，那么就很容易受到跨站请求伪造攻击。

session id

session id是一个会话的key，浏览器第一次访问服务器会在服务器端生成一个session，有一个session id和它对应。服务端在创建了Session的同时，会为该Session生成唯一的session Id，而session Id会在随后的请求中会被用来重新获得已经创建的Session；Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有sessionId；当客户端再次发送请求的时候，会将这个sessionId带上，服务器接受到请求之后就会依据sessionId找到相应的Session，从而再次使用之。

保存SessionID的方式：

1、一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把session id传递回服务器。

2、保存session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。

3、由于cookie可以被人为的禁止，必须有其它的机制以便在cookie被禁止时仍然能够session id传递回服务器，经常采用的一种技术叫做 URL重写，就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，另一种是作为查询字符串附加在 URL后面。网络在整个交互过程中终保持状态，就必须在每个客户端可能请求的路径后面都包含这个session id。

cookie生存周期

cookie分为会话cookie和持久cookie，会话cookie是指在不设定它的生命周期expires时的状态，前面说了，浏览器的开启到关闭就是一次会话，当关闭浏览器时，会话cookie就会跟随浏览器而销毁。当关闭一个页面时，不影响会话cookie的销毁。会话cookie就像我们没有办理积分卡时，单一的买卖过程，离开之后，信息则销毁。

持久cookie则是设定了它的生命周期expires，此时，cookie像商品一样，有个保质期，关闭浏览器之后，它不会销毁，直到设定的过期时间。对于持久cookie，可以在同一个浏览器中传递数据，比如，你在打开一个淘宝页面登陆后，你在点开一个商品页面，依然是登录状态，即便你关闭了浏览器，再次开启浏览器，依然会是登录状态。这就是因为cookie自动将数据传送到服务器端，在反馈回来的结果。持久cookie就像是我们办理了一张积分卡，即便离开，信息一直保留，直到时间到期，信息销毁。

cookie被禁止

手动通过URL传值、隐藏表单传递session id。
用文件、数据库等形式保存session_id,在跨页过程中手动调用。

参考博客

2.web缓存

Web 缓存大致可以分为：

数据库缓存
服务器端缓存（代理服务器缓存、CDN 缓存）
浏览器缓存

浏览器缓存包括：

HTTP 缓存
indexDB
cookie
localstorage

3.浏览器输入一个地址，到加载出页面中间发生了哪些过程

首先，在浏览器地址栏中输入url；
浏览器先查看浏览器缓存-系统缓存-路由器缓存，如果缓存命中，会直接在屏幕中显示页面内容。若没有，则跳到第三步操作；
在发送http请求前，需要域名解析(DNS解析)，解析获取相应的IP地址；
浏览器向服务器发起tcp连接，与浏览器建立tcp三次握手；
握手成功后，浏览器向服务器发送http请求，请求数据包，http请求也可能会触发缓存；
服务器处理收到的请求，将数据返回至浏览器；
浏览器收到HTTP响应；
读取页面内容，浏览器渲染，解析html源码；
生成Dom树、解析css样式、js交互；
客户端和服务器交互；
ajax查询。

其中，步骤3的具体过程是：

浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)；
路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
ISP（互联网服务提供商）缓存：若上述均失败，继续向ISP搜索。

其中，DNS解析的具体过程是：

先查看本地缓存、路由器缓存、ISP缓存；
如果缓存中都没有，就去请求根域名服务器、顶级域名服务器、主域名服务器（这有点像双亲委派机制，就是先交给最上面的部分处理，保证结果一致）；
最后将结果缓存的本地。
参考回答

4.跨域问题

浏览器在执行js脚本的时候，都会检查这个脚本属于哪个页面，即检查是否同源，只有同源的脚本才会被执行；而非同源的脚本在请求数据的时候，浏览器会报一个异常，提示拒绝访问。

同源策略限制的情况：
1、Cookie、LocalStorage 和 IndexDB 无法读取。
2、DOM 和 Js对象无法获得。
3、AJAX 请求不能发送。

解决方法：

服务器响应response中添加 header（跨域资源共享 CORS）

resp.setHeader("Access-Control-Allow-Origin", "*");

浏览器中js脚本使用ajax的jsonp

dataType:"jsonp",//数据类型为jsonp

HttpClient 请求转发
　这种方式客户端是向同源的项目发送请求，而不是和上面一样的向非同源的目标发送请求，然后在同源的后台通过 HttpClient 将请求发送到非同源的项目，得到数据后返回。这种方式相当于绕过浏览器的同源机制，直接通过后端进行转发。
nginx 转发
spring的注解@CrossOrigin这个和第一条原理类似参考博客

参考博客

5.JWT

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准.该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。
用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。

基于token的鉴权机制

基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利。

流程上是这样的：

用户使用用户名密码来请求服务器
服务器进行验证用户的信息
服务器通过验证发送给用户一个token
客户端存储token，并在每次请求时附送上这个token值
服务端验证token值，并返回数据

这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，另外，服务端要支持 CORS(跨域源资源共享)策略，一般我们在服务端这么做就可以了Access-Control-Allow-Origin: *。

跨域资源共享CORS详解

JWT详解

下列场景中使用JSON Web Token是很有用的：

Authorization (授权) : 这是使用JWT的最常见场景。一旦用户登录，后续每个请求都将包含JWT，允许用户访问该令牌允许的路由、服务和资源。单点登录是现在广泛使用的JWT的一个特性，因为它的开销很小，并且可以轻松地跨域使用。
Information Exchange (信息交换) : 对于安全的在各方之间传输信息而言，JSON Web Tokens无疑是一种很好的方式。因为JWT可以被签名，例如，用公钥/私钥对，你可以确定发送人就是它们所说的那个人。另外，由于签名是使用头和有效负载计算的，您还可以验证内容没有被篡改。
参考博客

6.REST

REST（英文：Representational State Transfer，简称REST）描述了一个架构样式的网络系统，比如 web 应用程序。其实就是URL定位资源，用HTTP动词（GET,POST,DELETE,DETC）描述操作。

REST的优点
以下摘自维基百科：

可更高效利用缓存来提高响应速度
通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
浏览器即可作为客户端，简化软件需求
相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
不需要额外的资源发现机制
在软件技术演进中的长期的兼容性更好
基于简单的文本格式消息和通用的HTTP协议，使它具备极广的适用性，几乎所有语言和平台都对它提供支持，同时其学习和使用的门槛也较低。

RESTful API
RESTful是一种架构的规范与约束、原则，符合这种规范的架构就是RESTful架构，RESTful API就是符合这种架构的接口规范。

7.DNS

DNS工作原理

第一步：客户机提出域名解析请求，并将该请求发送给本地的域名服务器。
第二步：当本地的域名服务器收到请求后，就先查询本地的缓存，如果有该纪录项，则本地的域名服务器就直接把查询的结果返回。
第三步：如果本地的缓存中没有该纪录，则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域) 的主域名服务器的地址。
第四步：本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没有该纪录，则返回相关的下级的域名服务器的地址。
第五步：重复第四步，直到找到正确的纪录。
第六步：本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时还将结果返回给客户机。

两种DNS解析方法

递归查询是最常见的查询方式，域名服务器将代替提出请求的客户机进行域名查询，若域名服务器不能直接回答，则域名服务器会在域各树中的各分支的上下进行递归查询，最终将返回查询结果给客户机，在域名服务器查询期间，客户机将完全处于等待状态；
迭代查询又称重指引，当服务器使用迭代查询时能使其他服务器返回一个最佳的查询点提示或主机地址，若此最佳的查询点中包含需要查询的主机地址，则返回主机地址信息，若此时服务器不能够直接查询到主机地址，则是按照提示的指引依次查询，直到服务器给出的提示中包含所需要查询的主机地址为止，一般每次指引都会更靠近根服务器，查寻到根域名服务器后，则会再次根据提示向下查找。