应用层
1、HTTP常见状态码?
分类
分类 |
范围 |
描述 |
1xx |
信息响应(100-199) |
代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。 |
2xx |
成功响应(200-299) |
代表请求已成功被服务器接收、理解、并接受 。 |
3xx |
重定向(300-399) |
表示要完成请求,需要进一步操作。通常,这些状态代码用来重定向 |
4xx |
客户端错误(400-499) |
代表了客户端看起来可能发生了错误,妨碍了服务器的处理。 |
5xx |
服务器错误(500-599) |
表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生。 |
2xx:
- 200(成功):请求已成功,请求所希望的响应头或数据体将随此响应返回
- 201(已创建):请求成功并且服务器创建了新的资源
- 202(已创建):服务器已经接收请求,但尚未处理
- 203(非授权信息):服务器已成功处理请求,但返回的信息可能来自另一来源
- 204(无内容):服务器成功处理请求,但没有返回任何内容
- 205(重置内容):服务器成功处理请求,但没有返回任何内容
- 206(部分内容):服务器成功处理了部分请求
3xx
- 300(多种选择):针对请求,服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择
- 301(永久移动):请求的网页已永久移动到新位置。服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置
- 302(临时移动):服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
- 303(查看其他位置):请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码
- 305 (使用代理):请求者只能使用代理访问请求的网页。如果服务器返回此响应,还表示请求者应使用代理
- 307 (临时重定向):服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
4xx
- 400(错误请求):服务器不理解请求的语法,它是客户端错误,因此该请求不能被服务器理解并执行。
- 401(未授权):请求要求身份验证。对于需要登录的网页,服务器可能返回此响应。
- 403(禁止):服务器拒绝请求。这通常意味着该资源不可用,或者服务器配置了对该资源的访问限制
- 404(未找到):服务器找不到请求的网页
- 405(方法禁用):禁用请求中指定的方法
- 406(不接受):无法使用请求的内容特性响应请求的网页
- 407(需要代理授权):此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理
- 408(请求超时):服务器等候请求时发生超时
5xx
- 500(服务器内部错误):服务器遇到错误,无法完成请求
- 501(尚未实施):服务器不具备完成请求的功能。例如,服务器无法识别请求方法时可能会返回此代码
- 502(错误网关):服务器作为网关或代理,从上游服务器收到无效响应
- 503(服务不可用):服务器目前无法使用(由于超载或停机维护)
- 504(网关超时):服务器作为网关或代理,但是没有及时从上游服务器收到请求
- 505(HTTP 版本不受支持):服务器不支持请求中所用的 HTTP 协议版本
一些状态码的适用场景:
- 206:一般用来做断点续传,或者是视频文件等大文件的加载
- 301:永久重定向会缓存。新域名替换旧域名,旧的域名不再使用时,用户访问旧域名时用301就重定向到新的域名
- 302:临时重定向不会缓存,常用 于未登陆的用户访问用户中心重定向到登录页面
- 304:协商缓存,告诉客户端有缓存,直接使用缓存中的数据,返回页面的只有头部信息,是没有内容部分
- 400:参数有误,请求无法被服务器识别
- 403:告诉客户端禁止访问该站点或者资源,如在外网环境下,然后访问只有内网IP才能访问的时候则返回
- 404:服务器找不到资源时,或者服务器拒绝请求又不想说明理由时
- 503:服务器停机维护时,主动用503响应请求或 nginx 设置限速,超过限速,会返回503
- 504:网关超时
2、HTTP方法有哪些?
方法 |
作用 |
GET |
获取资源 |
POST |
向服务器添加数据 |
PUT |
上传文件 |
DELETE |
删除文件 |
HEAD |
和GET方法类似,但只返回报文首部,不返回报文实体主体部分 |
PATCH |
对资源进行部分修改 |
OPTIONS |
查询指定的URL支持的方法 |
CONNECT |
要求用隧道协议连接代理 |
TRACE |
服务器会将通信路径返回给客户端 |
为了方便记忆,可以将PUT、DELETE、POST、GET理解为客户端对服务端的增删改查:
- PUT:上传文件,向服务器添加数据,可以看作增;
- DELETE:删除文件;
- POST:传输数据,向服务器提交数据,对服务器数据进行更新;
- GET:获取资源,查询服务器资源;
3、GET 和 POST 的区别?
- 从请求参数来看:
- GET 提交的数据会放在 URL 之后,并且请求参数会被完整的保留在浏览器的记录里,由于参数直接暴露在 URL 中,可能会存在安全问题,因此往往用于获取资源信息;
- 而 POST 参数放在请求主体中,并且参数不会被保留,相比 GET 方法,POST 方法更安全,主要用于修改服务器上的资源。
- 从提交数据来看:
- GET 提交的数据大小有限制,而 POST 方法提交的数据没限制;
- GET 请求只支持 URL 编码,POST 请求支持多种编码格式;
- GET 只支持 ASCII 字符格式的参数,而 POST方法没有限制。
- 从是否幂等性来看:
- GET 请求用于查看信息,不会改变服务器上的信息;而 POST 请求用来改变服务器上的信息。正因为 GET 请求只查看信息,不改变信息,对数据库的一次或多次操作获得的结果是一致的,认为它符合幂等性。
- 幂等性是指一次和多次请求某一个资源应该具有同样的副作用。简单来说意味着对同一URL的多个请求应该返回同样的结果。
- 从其他层面来看:
- GET 请求能够被缓存,GET 请求能够保存在浏览器的浏览记录里,GET 请求的 URL 能够保存为浏览器书签。这些都是 POST 请求所不具备的,缓存是 GET 请求被广泛应用的根本。
4、HTTP方法的幂等性?
HTTP方法的幂等性:指一次和多次请求某一个资源应该具有同样的副作用,这里的副作用是指资源状态。
- GET方法:GET 方法用来查看信息,不会改变服务器上的信息,所以是幂等的;
- PUT方法:PUT 方法用来修改资源的内容,但是不会增加资源的种类,也就是说PUT 方法通常是对已经存在的资源进行修改,所以是幂等的;
- POST方法:POST 方法用来新增资源,所以不是幂等的;
- DELETE方法:DELETE方法用来删除资源,调用一次和多次对资源产生影响是相同的,所以也满足幂等性;
总结:GET方法,PUT方法,DELETE方法是幂等性的,POST方法不是幂等性的。
5、HTTP请求与响应报文格式?
请求报文格式: 请求行(请求方法+url地址+ HTTP版本)、请求头(key-value键值对)、空格、请求体。
响应报文格式: 状态行(HTTP版本+状态码+状态值)、响应头(key-value键值对)、空格、响应体。
6、HTTP协议的优缺点?
HTTP是一种用于在万维网(WWW)上传输超文本的协议。HTTP是由请求-响应模型构建的,即客户端向服务器发送请求,服务器响应请求并返回数据。
优点:
- 简单易用:HTTP是一种简单的协议,可以使用现成的库来发送和接收请求,因此开发人员可以快速构建基于HTTP的应用程序。
- 可扩展性:HTTP允许开发人员使用扩展头来扩展协议的功能,因此可以根据需要添加新的功能。
- 跨平台:HTTP可以在所有主流操作系统和浏览器上使用,因此可以在多个平台之间传输数据。
缺点:
- 无法保证数据的完整性和保密性:HTTP本身不包含安全机制,因此不能保证数据的完整性和保密性。要解决这个问题,需要使用其他协议,例如HTTPS。
- 效率较低:HTTP 1.0每次请求都必须建立新的连接,这降低了效率。
- 无法实现双向通信:HTTP是一种单向协议,只能由客户端发起请求,无法实现双向通信。
7、HTTP1.0协议的优缺点?
优点:
- 简单易用:HTTP 1.0协议非常简单,客户端和服务器之间的通信也非常简单,使用起来十分方便。
- 通用性强:HTTP 1.0协议能够运行在几乎所有的操作系统和计算机平台上,并且能够被所有的浏览器支持,因此在当时十分流行。
- 可扩展性强:HTTP 1.0协议允许扩展HTTP报头,以满足不同的需求。
缺点:
- 每次请求都必须建立一个新的TCP连接,在连接数量较多的情况下会对服务器造成压力,并且连接建立和断开的开销也比较大。
- 不支持长连接,也就是说在一次HTTP请求完成后,客户端和服务器之间的TCP连接就会断开,如果要发送下一个请求就必须重新建立连接。这样会导致大量的连接建立和断开的开销,降低了网络效率。
- 不支持断点续传,也就是说如果要下载一个较大的文件,在下载过程中如果网络出现中断,那么客户端必须从头开始下载,而不能从上次中断的地方继续下载。
- 不支持压缩,也就是说如果要传输的数据很大,那么就需要消耗大量的带宽。
8、HTTP 1.0和HTTP 1.1的主要区别是什么?
HTTP1,.0是第一个在通讯中指定版本号的HTTP协议版本,至今仍被广泛采用。HTTP 1.1是目前主流的HTTP协议版本,主要区别如下:
- 长连接: 在HTTP/1.0中,默认使用的是短连接,也就是说每次请求都要重新建立一次连接。而每一次连接或者断开连接都需要三次握手四次挥手的开销,这样开销会比较大。HTTP/1.1 默认使用的是持久连接,其支持在同一个 TCP 请求中传送多个 HTTP 请求和响应。如果想要在旧版本的 HTTP 协议上维持持久连接,则需要指定 Connection 的首部字段的值为Keep-Alive。
- 错误通知的管理:HTTP/1.1 在 1.0 的基础上新增了 24 个错误状态响应码,例如:414 表示客户端请求中所包含的 URL 地址太长,以至于服务器无法处理;410 表示所请求的资源已经被永久删除。
- 缓存处理:在 HTTP/1.0 中主要使用 header 里的 if-modified-Since, Expries 来做缓存判断的标准。而 HTTP/1.1 请求头中添加了更多与缓存相关的字段,从而支持更为灵活的缓存策略,例如Entity-tag, If-Unmodified-Since, If-Match, If-None-Match 等可供选择的缓存头来控制缓存策略。
- 节约带宽: 当客户端请求某个资源时,HTTP/1.0 默认将该资源相关的整个对象传送给请求方,但很多时候可能客户端并不需要对象的所有信息。而在 HTTP/1.1 的请求头中引入了 range 头域,它允许只请求部分资源,其使得开发者可以多线程请求某一资源,从而充分的利用带宽资源,实现高效并发。
9、HTTP/1.1和HTTP/2.0的主要区别是什么?
主要区别如下:
- 二进制格式传输:相比于 HTTP/1.0 的文本(字符串)传送, HTTP/2.0 采用二进制传送。客户端和服务器传输数据时把数据分成帧,帧组成了数据流,流具有流 ID 标识和优先级,通过优先级以及流依赖能够一定程度上解决关键请求被阻塞的问题。
- HTTP/2.0 支持多路复用: HTTP/2.0 支持多路复用。因为流 ID 的存在,通过同一个 HTTP 请求可以实现多个 HTTP 请求传输,客户端和服务器可以通过流 ID 来标识究竟是哪个流从而定位到是哪个 HTTP 请求。
- HTTP/2.0 头部压缩:HTTP/2.0 通过 gzip 和 compress 压缩头部然后再发送,同时通信双方会维护一张头信息表,所有字段都记录在这张表中,在每次 HTTP 传输时只需要传头字段在表中的索引即可,大大减小了重传次数和数据量。
- HTTP/2.0 支持服务器推送: 服务器在客户端未经请求许可的情况下,可预先向客户端推送需要的内容,客户端在退出服务时可通过发送复位相关的请求来取消服务端的推送。
10、HTTP/3了解吗?
HTTP/3主要有两大变化,传输层基于UDP、使用QUIC保证UDP可靠性。
HTTP/3主要有这些特点:
- 使用UDP作为传输层进行通信;
- 在UDP的基础上QUIC协议保证了HTTP/3的安全性,在传输的过程中就完成了TLS加密握手;
- HTTPS 要建立一个连接,要花费 6 次交互,先是建立三次握手,然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次,减少了交互次数。
- QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时,只会阻塞这个流,其他流不会受到影响。
HTTP协议变迁:
11、HTTP长连接和短连接?
长连接
- 概念: 一次TCP连接,多次HTTP通信。
- 优点: 长连接可以省去较多的TCP建立/关闭的操作,减少浪费,节省时间,对于频繁请求资源的客户,较适用于长连接。
- 缺点:维持较多的长连接对服务器是一个很大的负担。
- 使用场景: 多用于操作频繁,点对点的通讯,而且客户端连接数目较少的情况。例如即时通讯、网络游戏。
短连接
- 概念:一次连接,一次通信。
- 优点:短连接对于服务器来说较为简单,存在的连接都是有用的连接,不需要额外的控制
- 缺点:如果客户请求频繁,将在TCP的建立和关闭操作上浪费时间和带宽。
- 使用场景: 用户数目较多的Web网站的 HTTP 服务一般用短连接。例如京东,淘宝这样的大型网站一般客户端数量达到千万级甚至上亿,若采用长连接势必会使得服务端大量的资源被无效占用,所以一般使用的是短连接。
如何设置长连接?
通过在头部(请求和响应头)设置 Connection 字段指定为keep-alive,HTTP/1.0 协议支持,但是是默认关闭的,从 HTTP/1.1 以后,连接默认都是长连接。
12、一个TCP连接可以同时处理多少次HTTP请求?
HTTP版本不同,一个TCP连接可以同时处理的HTTP请求次数也不同:
- HTTP 1.0 版本协议,默认使用的是短连接,一般情况下,不支持长连接,因此在每次请求发送完毕之后,TCP 连接即会断开,因此一个 TCP发送一个 HTTP 请求。如果想要将一条 TCP 连接保持在活跃状态,我们可以指定 Connection 的首部字段的值为Keep-Alive,这样一个TCP连接便可以处理多次HTTP请求;
- HTTP 1.1 版本协议,支持了长连接,因此只要 TCP 连接不断开,便可以一直发送 HTTP 请求,持续不断,没有上限;
- HTTP 2.0 版本协议,支持多用复用,一个 TCP 连接是可以并发多个 HTTP 请求的,同样也是支持长连接,因此只要不断开 TCP 的连接,HTTP 请求数也是可以没有上限地持续发送。
13、对称加密算法与非对称加密算法?
对称加密: 使用同一把密钥进行加密解密,运算速度快,安全性较低。
非对称加密: 使用公钥对传输数据加密,再使用密钥对数据解密,运算速度慢更耗资源,安全性更高。
区别:
- 加密算法不同
- 非对称加密中使用的主要算法有:RSA、Elgamal、背包算法 、Rabin、D-H、ECC(椭圆曲线加密算法)等。
- 对称加密中使用的主要算法有:DES、3DES、 AES 等
- 加密安全性不同
- 对称加密的通信双方使用相同的秘钥,如果一方的秘钥遭泄露,那么整个通信就会被破解。
- 非对称加密使用一对秘钥,一个用来加密,一个用来解密,而且公钥是公开的,秘钥是自己保存的,不需要像对称加密那样在通信之前要先同步秘钥。非对称加密与对称加密相比,其安全性更好。
- 加密耗时不同
- 非对称加密使用一对秘钥,一个用来加密,一个用来解密,这样加密和解密花费时间就会更长。
- 对称加密中加密方和解密方使用同一个密钥,加密解密的速度比较快,耗时短,适合数据比较长时的使用。
14、常用的加密算法介绍?
- AES:AES是一种对称加密算法,也就是说加密和解密使用的是同一个密钥。AES算法可以使用128、192或256位密钥,并且采用分组密码的方式,对数据分组进行加密。AES算法被认为是目前最安全的对称加密算法。
- RSA:RSA是一种非对称加密算法,也就是说加密和解密使用的是不同的密钥。RSA算法使用两个密钥,一个是公开的密钥,另一个是私有的密钥。使用公开的密钥可以对数据进行加密,而使用私有的密钥可以对加密后的数据进行解密。RSA算法的安全性主要依赖于密钥的长度,目前常用的密钥长度是2048位。
- DES:DES是一种对称加密算法,使用56位密钥,采用分组密码的方式对数据进行加密。DES算法已经被认为是不够安全的,因此被AES算法取代。
- MD5:MD5是一种散列算法,用于将任意长度的数据转换为固定长度的摘要信息。MD5算法生成的摘要信息长度为128位,并且是不可逆的,也就是说无法通过摘要信息推断出原始数据。MD5算法常用于数字签名、文件校验等场景。
15、数字签名和数字证书区别与联系?
- 数字签名是使用数字证书与信息加密技术、用于鉴别电子数据信息的技术,可通俗理解为加盖在电子文件上的“数字指纹”。
- 数字证书是由权威公证的第三方认证机构(即CA,Certificate Authority)负责签发和管理的、个人或企业的网络数字身份证明。
- 数字签名是用数字证书对电子文件签名后在电子文件上保留的签署结果,用以证明签署人的签署意愿。所以数字证书是数字签名的基础,数字签名是数字证书的一种应用结果。
16、HTTPS是什么?
- HTTPS并不是应用层的一种新协议。
- HTTPS协议是指:HTTP协议+加密处理+身份认证+完整性保护(HTTP协议+SSL协议/TLS协议)
- 通常,HTTP协议会直接和TCP通信,而使用HTTPS,则变成了HTTP先和SSL通信,再由SSL和TCP通信。一般,将SSL统称SSL+TLS。
17、HTTPS 的加密方式?
HTTPS 采用对称加密和非对称加密相结合的方式:
- 首先使用 SSL/TLS 协议进行加密传输;
- 为了弥补非对称加密的缺点,HTTPS 采用证书来进一步加强非对称加密的安全性;
- 通过对称加密,客户端和服务端协商好之后进行通信传输的对称密钥,后续的所有信息都通过该对称秘钥进行加密解密,完成整个HTTPS 的流程。
18、HTTP与HTTPS的区别? ⚡
- 安全: HTTP 协议以明文方式发送内容,数据都是未加密的,安全性较差。HTTPS 数据传输过程是加密的,安全性较好。
- 端口:HTTP 的端口号是 80,HTTPS 的端口号是 443。
- 效率:HTTP 页面响应比 HTTPS 快,主要因为 HTTP 使用 3 次握手建立连接,客户端和服务器需要握手 3 次,而 HTTPS 除了 TCP 的 3 次握手,还需要经历一个 SSL 协商过程。
- 资源消耗:HTTP资源消耗较少,而HTTPS由于需要加密处理,资源消耗更多。
- 协议:HTTP运行在TCP协议之上,HTTPS运行在SSL协议之上,SSL运行在TCP协议之上。
19、为什么要用HTTPS?解决了哪些问题?
因为HTTP 是明文传输,存在安全上的风险:
- 窃听风险,比如通信链路上可以获取通信内容,用户账号被盗;
- 篡改风险,比如强制植入垃圾广告,视觉污染;
- 冒充风险,比如冒充淘宝网站,用户金钱损失。
HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议,可以很好的解决了这些风险
- 信息加密:交互信息无法被窃取。
- 校验机制:无法篡改通信内容,篡改了就不能正常显示。
- 身份证书:能证明淘宝是真淘宝。
所以SSL/TLS 协议是能保证通信是安全的。
20、HTTPS 的优缺点?
优点:
- 安全性:
- 使用HTTPS协议可认证用户和服务器,确保数据发送到正确的客户机和服务器。
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全,可防止数据在传输过程中不被窃取、改变,确保数据的完整性。
- HTTPS是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
- SEO方面:谷歌曾在2014年8月份调整搜索引擎算法,并称“比起同等HTTP网站,采用HTTPS加密的网站在搜索结果中的排名将会更高”。
缺点:
- 在相同网络环境中,HTTPS 相比 HTTP 无论是响应时间还是耗电量都有大幅度上升。
- HTTPS 的安全是有范围的,在黑客攻击、服务器劫持等情况下几乎起不到作用。
- 在现有的证书机制下,中间人攻击依然有可能发生。
- HTTPS 需要更多的服务器资源,也会导致成本的升高。
21、HTTPS工作流程是怎样的?
HTTPS主要工作过程:
- 客户端发起 HTTPS 请求,连接到服务端的 443 端口。
- 服务端有一套数字证书(证书内容有公钥、证书颁发机构、失效日期等)。
- 服务端将自己的数字证书发送给客户端(公钥在证书里面,私钥由服务器持有)。
- 客户端收到数字证书之后,会验证证书的合法性。如果证书验证通过,就会生成一个随机的对称密钥,用证书的公钥加密。
- 客户端将公钥加密后的密钥发送到服务器。
- 服务器接收到客户端发来的密文密钥之后,用自己之前保留的私钥对其进行非对称解密,解密之后就得到客户端的密钥,然后用客户端密钥对传输数据进行对称加密,这样传输的数据都是密文。
- 服务器将加密后的密文返回到客户端。
- 客户端收到后,用自己的密钥对其进行对称解密,得到服务器返回的数据。
22、SSL/TLS握手过程?
- "client hello"消息:客户端通过发送"client hello"消息向服务器发起握手请求,该消息包含了客户端所支持的 TLS 版本和密码组合以供服务器进行选择,还有一个"client random"随机字符串。
- "server hello"消息:服务器发送"server hello"消息对客户端进行回应,该消息包含了数字证书,服务器选择的密码组合和"server random"随机字符串。
- 验证:客户端对服务器发来的证书进行验证,确保对方的合法身份,验证过程可以细化为以下几个步骤:
- 检查数字签名
- 验证证书链 (这个概念下面会进行说明)
- 检查证书的有效期
- 检查证书的撤回状态 (撤回代表证书已失效)
- "premaster secret"字符串:客户端向服务器发送另一个随机字符串"premaster secret (预主密钥)",这个字符串是经过服务器的公钥加密过的,只有对应的私钥才能解密。
- 使用私钥:服务器使用私钥解密"premaster secret"。
- 生成共享密钥:客户端和服务器均使用 client random,server random 和 premaster secret,并通过相同的算法生成相同的共享密钥 KEY。
- 客户端就绪:客户端发送经过共享密钥 KEY加密过的"finished"信号。
- 服务器就绪:服务器发送经过共享密钥 KEY加密过的"finished"信号。
- 达成安全通信:握手完成,双方使用对称加密进行安全通信。
23、Cookie与Session?
Cookie:
- Cookie 是保存在客户端的一小块文本串的数据。客户端向服务器发起请求时,服务端会向客户端发送一个 Cookie,客户端就把 Cookie 保存起来。在客户端下次向同一服务器再发起请求时,Cookie 被携带发送到服务器。服务端可以根据这个Cookie判断用户的身份和状态。
Session:
- Session 指的就是服务器和客户端一次会话的过程。它是另一种记录客户状态的机制。不同的是cookie保存在客户端浏览器中,而session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上,这就是session。客户端浏览器再次访问时只需要从该session中查找用户的状态。
24、Cookie和Session的区别?
- 存储位置不同:Cookie 保存在客户端,Session 保存在服务器端。
- 存储数据类型不同:Cookie 只能保存ASCII,Session可以存任意数据类型,一般情况下我们可以在 Session 中保持一些常用变量信息,比如说 UserId 等。
- 有效期不同:Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般有效时间较短,客户端关闭或者 Session 超时都会失效。
- 用途不同:Cookie一般存用户信息(Token),Session一般通过服务器记录用户状态(购物车)。
- 隐私策略不同:Cookie 存储在客户端,比较容易遭到不法获取,早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取;Session 存储在服务端,安全性相对 Cookie 要好一些。
- 存储大小不同: 单个Cookie保存的数据不能超过4K,Session可存储数据远高于 Cookie。
25、Session 和 Cookie有什么关联呢?
可以使用Cookie记录Session的标识:
- 用户第一次请求服务器时,服务器根据用户提交的信息,创建对应的 Session,请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器,浏览器接收到服务器返回的 SessionID 信息后,会将此信息存入 Cookie 中,同时 Cookie 记录此 SessionID 是属于哪个域名。
- 当用户第二次访问服务器时,请求会自动判断此域名下是否存在 Cookie 信息,如果存在,则自动将 Cookie 信息也发送给服务端,服务端会从 Cookie 中获取 SessionID,再根据 SessionID 查找对应的 Session 信息,如果没有找到,说明用户没有登录或者登录失效,如果找到 Session 证明用户已经登录可执行后面操作。
26、使用Redis实现Seeion共享?
场景: 由于分布式环境下,对于多台服务器,当客户端请求服务器A,创建Session,返回携带SessionID的Cookie给客户端,下次客户端访问服务器B根据Sessionid得不到Session,就有问题。
解决: 可以用Redis解决,比如将用户信息存入Redis,Key为SessionID,返回携带SessioniD的Cookie给客户端,下次访问携带Cookie,通过Sessionid从Redis取出相关信息。
27、禁止cookie的情况下如何使用session?
- 拼接到URL里:直接把SessionID作为URL的请求参数
- 放到请求头里:把SessionID放到请求的Header里,比较常用
28、DNS使用什么协议?
DNS 既使用 TCP 又使用 UDP:
- 当域名服务器之间进行数据同步时,需要保证数据一致性,要求可靠,因此使用TCP;
- 当客户端向 DNS 服务器查询域名( 域名解析) 的时候,用 UDP 传输时,不需要经过 TCP 三次握手的过程,从而大大提高了响应速度。