文章目录
HTTP请求
介绍下HTTP
- HTTP协议是面向事务的应用层协议,它规定了在浏览器和服务器之间的请求和响应格式
- HTTP协议是无连接的
- 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间,并且可以提高并发性能,不能和每个用户建立长久的连接,请求一次相应一次,服务端和客户端就中断了。
- 但是无连接有两种方式,早期的http协议是一个请求一个响应之后,直接就断开了,但是现在的http协议1.1版本不是直接就断开了,而是等几秒钟,这几秒钟是等什么呢,等着用户有后续的操作,如果用户在这几秒钟之内有新的请求,那么还是通过之前的连接通道来收发消息,如果过了这几秒钟用户没有发送新的请求,那么就会断开连接,这样可以提高效率,减少短时间内建立连接的次数,因为建立连接也是耗时的,默认的好像是3秒中现在,但是这个时间是可以通过咱们后端的代码来调整的,自己网站根据自己网站用户的行为来分析统计出一个最优的等待时间。
- HTTP协议是无状态协议。
- 无状态指每次的请求都是独立的,它的执行情况和结果与前面的请求和之后的请求是无直接关系的,它不会受前面的请求应答情况直接影响,也不会直接影响后面的请求应答情况
- HTTP协议 自身不对请求和响应之间的通信状态进行保存。也就是说在HTTP这个 级别,协议对于发送过的请求或响应都不做持久化处理。
- 比如,用户登录到一家购物网站,即使他跳转到该站的 其他页面后,也需要能继续保持登录状态。针对这个实例,网站为了能 够掌握是谁送出的请求,需要保存用户的状态。HTTP/1.1虽然是无状态协议,但为了实现期望的保持状态功能, 于是引入了Cookie技术。有了Cookie再用HTTP协议通信,就可以管 理状态了。有关Cookie的详细内容稍后讲解。
其他协议的状态
TCP为一个有状态的传输层通信协议,而UDP则不是;IP是无状态的。要明白这种有状态与否的判定,是指你这一协议栈层次所要实现的功能——是否由上下文决定——来判定的(是否受之前的通信过程直接影响、是否直接影响之后的通信过程)
原因
-
IP是无状态的,它只负责将一个IP包发送到指定的IP地址上去。它不会考虑这个包与前面已经发送的包和后面的包的联系。(可能是重发包、可能是不连续包,它不管)。
-
TCP是有状态的,它通过包头中的一些控制字段(序列编码等)来表明各个包之间的关系(前后关系,重包与否等等)。所以,通过这个协议你可以做到一个可靠的传输。那么TCP是面向连接的协议是什么意思呢?其实这里的面向连接其实就是“三次握手”。三次握手,首先可以保证对方的存在,其次握手的所交换的内容是为将来进行有状态的传输做准备。
-
UDP是无状态的,它仅仅是在IP上加了Port,其他的事情什么也不干。这样它不可能做到可靠的传输,同样也不需要连接。
-
HTTP是无状态的,它的底层协议是由状态的TCP,但是HTTP的一次完整协议动作,里面是使用有状态的TCP协议来完成的。而每次协议动作之间没有任何关系。例如:第7次请求HTTP协议包,并不知道,这个包是为了什么?它或许是因为上次没有请求成功而重传,或许是上次的后续请求,或许是其他的,这些HTTP自身都不知道。
-
www应用,很多时候,www应用是需要每个HTTP请求或应答动作之间是有关联的,那就是使应用有状态。这样才能提供给用户最好的用户体验。
HTTP请求头格式
提示: 回车符 \r 换行符 \n
请求首行分析
请求头部分析
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
表示客户端可以接受的内容类型,多个值使用;分号隔开q=0.9 表示权重优先级,*/*表示可以接受任意类型内容;Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
表示客户端可以接受的语言User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64x64;
Accept-Encoding: gzip, deflate
–>>支持的压缩格式Host: localhost:8888
访问地址Connection: keep-alive
保持连接 和HTTP1.1版本有关,默认保持3sContent-Type: application/x-www-form-urlencoded
表单提交时才有可能出现,表示表单的数据类型,使用url编码,url编码 % 16位数Content-Length: 7
—>post请求 请求体长度Upgrade-Insecure-Requests: 1
–>>告诉服务器,浏览器可以处理https协议、
请求空行分析:
就是一个分隔符,用来区分请求头和请求体的;
请求体分析:
只有POST请求才有请求体, 因此 POST请求 请求体中存放的是表单提交的键值对。
例如:name=’zs’&age=10
HTTP响应格式
响应首行(状态行)分析:
HTTP/1.1 200 OK
包含 协议–>>HTTP/1.1, 响应码(状态码)—>>200 , 状态码描述—>>OK
状态码:
- 200: 服务器很好的处理了客户端的请求,一切 OK
- 302: 重定向(发生两次请求)
例如经常去一家饭店吃饭,突然某一天饭店搬迁,只剩下一个门,门上写着新店在左边100米处,然后你根据纸条找到新饭店;302就相当于门上的条,当你访问一个网站时他给你返回302你需要重新访问新的网址; 这里面发生了2次请求 - 304:通常表示资源文件在服务器没有更改,而浏览器端又有缓存,这时候回送 304 状体码通知浏览器拿本地的缓存显示。
- 404:表示客户端访问的资源路径有问题或者资源问题不存在。
- 500:表示服务器出现了 异常.
响应头部分析
server: Apache-Coyote/1.1
—>> 服务器版本号
Content-Type: text/html;charset=utf-8
响应字符集,告诉浏览器以什么样的字符集解码;
Content-Length: 265
响应体长度
Date: Fri, 23 Jun 2017 13:45:01 GMT
发送日期 少8个小时;
Expires: -1、Cache-control:no-cache、Pragma:no-cache
三个响应头一起使用, 表示禁止浏览器缓存当前页面. 每个浏览器厂商对认识的禁止头不同因此三个一起使用。
get和post的区别
- get,通过拼接url进行传递参数 ,post通过body体传输参数
- GET产生一个TCP数据包,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
POST产生两个TCP数据包,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200
并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次
而对于POST,浏览器先发送header,然后再发送data,服务器响应200 ok(返回数据);
所以,一般来说POST时间上消耗的要多一点,GET比POST更有效
两次包的TCP在验证数据包完整性上,有非常大的优点。 - get请求页面后退时,不产生影响,post请求页面后退时,会重新提交请求
- get请求是可以缓存的
post请求不可以缓存,除非手动设置 - get请求在url中传递的参数是有长度限制的,一般是2048字符,而post没有
- GET只接受ASCII字符的参数的数据类型,而POST没有限制
- GET和POST本质上就是TCP链接,并无差别。但是由于HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同
一次完整的HTTP事务流程
- 域名解析
- 发起TCP的三次握手
- 建立TCP连接后发起http请求
- 服务器响应http请求,浏览器得到HTML代码
- 浏览器解析HTML代码,并请求HTML代码中的资源
- 浏览器对页面进行渲染呈现给用户
- 连接结束
浏览器缓存机制
HTTP-304状态码-304状态码是在协商缓存,缓存命中的时候服务器返回的,告诉客户端,服务器资源没有修改,可以使用客户端自己的缓存。
浏览器缓存分为强缓存(本地缓存)和协商缓存(弱缓存)。
如上图所示,在浏览器第一次发出请求之后,需要再次发送请求的时候,浏览器首先获取该资源缓存的 header 信息,然后根据 Cache-Control 和 Expires 字段判断缓存是否过期。如果没有过期,直接使用浏览器缓存,并不会与服务器通信。该过程为判断是否使用强缓存,即本地缓存。
1、Cache-Control
该字段是 HTTP1.1 规范,一般利用该字段的 max-age 属性来判断,这个值是一个相对时间,单位为 s,代表资源的有效期。例如:
Cache-Control:max-age=3600
除此之外还有几个常用的值:
- no-cache:表示不使用强缓存,需要使用协商缓存
- no-store:禁止浏览器缓存数据,每次请求下载完整的资源
- public:可以被所有用户缓存,包括终端用户和中间代理服务器
- private:只能被终端用户的浏览器缓存
2 、Expires
该字段是 HTTP1.0 规范,他是一个绝对时间的 GMT 格式的时间字符串。例如:
expires:Mar, 06 Apr 2020 10:57:09 GMT
这个时间代表资源的失效时间,只要发送请求的时间在这之前,都会使用强缓存。
由于失效时间是一个绝对时间,因此当服务器时间与客户端时间偏差较大时,就会导致缓存混乱。
如果缓存过期,浏览器会向服务器发送请求,即使用协商缓存。本次请求会带着第一次请求返回的有关缓存的 header 字段信息,比如以下两个字段:
-
Etag/If-None-Match
判断响应头中是否存在 Etag 字段,如果存在,浏览器则发送一个带有 If-None-Match 字段的请求头的请求,该字段的值为 Etag 值。服务器通过对比客户端发过来的Etag值是否与服务器相同。如果相同,说明缓存命中,服务器返回 304 状态码,并将 If-None-Match 设为 false,客户端继续使用本地缓存。如果不相同,说明缓存未命中,服务器返回 200 状态码,并将 If-None-Match 设为 true,并且返回请求的数据。
-
Last-Modified/If-Modified-S***rong>
除了 Etag 字段之外,客户端还会通过服务器返回的 Last-Modified 字段判断是否继续使用缓存,该字段为服务器返回的资源的最后修改时间,为UMT时间。浏览器发送一个带有 If-Modified-Since 字段的请求头的请求给服务器,该字段的值为 Last-Modified 值。服务器收到之后,通过这个时间判断,在该时间之后,资源有无修改,如果未修改,缓存命中,返回 304 状态码;如果未命中,返回 200 状态码,并返回最新的内容。
Cache-Control 与 Expires 的优先级:
两者可以在服务端配置同时使用,Cache-Control 的优先级高于 Expires。
Last-Modified/If-Modified-Since 已经可以判断缓存是否失效了,为什么出现 Etag/If-None-Match?
Etag/If-None-Match 是实体标签,是一个资源的唯一标识符,资源的变化都会导致 ETag 的变化。出现 Etag 的主要原因是解决 Last-Modified 比较难解决的问题:
- 一些文件也许会周期性的修改,但是他的内容并不发生改变,这个时候我们并不希望客户端认为这个文件修改了
- 某些文件在秒以下的时间内进行修改了,If-Modified-Since无法判断。UNIX时间只能精确到秒
Last-Modified 和 Etag 可以一起使用, Etag 的优先级更高。
刷新页面的问题:
-
F5刷新:不使用强缓存,使用协商缓存
-
ctrl+F5:二者都不使用
HTTP与HTTPS的区别及实现方式
基本概念
HTTP是超文本传输协议,是一个简单的请求-响应协议,它默认工作在TCP的80端口。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。协议以明文的方式进行发送,不提供任何方式的数据加密。因此HTTP协议不适合传输一些敏感信息
HTTPS是超文本传输安全协议,是一种安全通信的传输协议。HTTPS经由HTTP进行通信,但利用 SSL/TSL 来进行加密数据包。HTTPS开发的主要目的是提供网站服务器的身份认证,保护数据交换的隐私与完整性。
HTTPS默认工作在 TCP 的443 端口,它的工作方式如下:
- TCP三次同步握手
- 客户端验证服务端数字证书
- DH 算法协商对称加密加密算法的密钥、hash 算法的密钥
- SSL 安全加密隧道协商完成
- 网页以加密的方式进行传输,用协商的对称加密算法和密钥加密,保障数据机密性;用协商的 hash 算法进行数据完整性保护,保证数据不被篡改。
HTTP 与 HTTPS 的区别
- HTTP 使用明文传输,数据都是未加密的,安全性较差;HTTPS 数据传输过程是加密的,安全性较好;
- 使用 HTTPS 一般需要到 CA 申请证书
- HTTP页面的响应比 HTTPS 快,主要是因为 HTTPS 除了 TCP 的三个包之外,还要加上 ssl 握手的 9 个包
- HTTP 和 HTTPS 是完全不同连接方式,用的端口也不一样, 前者是80, 后者是 443
HTTPS 其实就是建构在 SSL/TSL 之上的 HTTP 协议,所以要比 HTTP 更消耗服务器资源
- 客户端发起 HTTPS 请求
建立TCP连接之后,客户端发起请求
- 服务端的配置
服务端收到请求之后,会有一套公钥和私钥,这对公钥和私钥其实就是一套数字证书,一般都是由受信任的证书颁发机构进行签发。
- 传送公钥
服务端将公钥传递给客户端,里面包含很多信息,如证书的颁发机构,证书的过期时间
- 客户端解析证书
这部分工作由客户端的 TSL 来完成,首先验证证书是否有效。如果没有问题,就会随机生成一个 key,然后利用公钥对 key 的值进行加密。
- 传送加密的信息(key)
将加密过后的 key 传递给服务器
- 使用私钥解析加密信息(key)
服务器使用自己的私钥解密加密信息得到 key
- 使用客户端的 key,利用对称加密加密信息,并发送给客户端
把内容通过该 key 进行对称加密,并传输给客户端
- 客户端使用 key 解密信息
客户端收到信息之后利用 key 进行解密
重点
重点:客户端会生成 key,key 的传输使用非对称加密,而数据的传输使用 key 进行对称加密。
- 对称加密:加密密钥和解密密钥是同一个,效率较高
- 非对称加密:加密密钥和解密密钥不是同一个,效率较低
由于非对称加密的效率比较低,因此我们通常不使用非对称加密对整个文件进行加密,而采用对称加密对文件加密,非对称加密对对称加密的密钥加密,然后将对称加密后的文件和非对称加密后的密钥一起在网上传送。
SSL 的位置
在发送方,SSL接受应用层的数据(如HTTP或者IMAP报文),对数据进行加密,然后把加了密的数据送往TCP套接字。
在接收方,SSL从TCP套接字读取数据,解密后把数据交给应用层。
使用非对称加密进行文件传输。通信双方在传输时需要交换各自的公钥。
作者:来个offer吧!!!!
链接:https://www.nowcoder.com/discuss/634359?type=all&order=time&pos=&page=1&channel=-1&source_id=search_all_nctrack
来源:牛客网
SSL提供以下三个功能:
-
SSL服务器鉴别:允许用户证实服务器的身份。具有SSL功能的浏览器维持一个表,上面有一些可信赖的认证中心CA(Certificate Authority)和它们的公钥。
-
加密的SSL会话:客户和服务器交互的所有数据都在发送方加密,在接收方解密。
-
SSL客户鉴别:允许服务器证实客户的身份。
HTTP1.0与HTTP1.1以及HTTP2,0的区别
-
长连接
在HTTP1.0中,TCP每建立一次连接就只能发送一个 HTTP 请求并得到一个响应,当需要再次发送请求的时候,又得重新建立 TCP 连接,这样就会很耗时间,传输效率较低。
HTTP1.1中支持长连接和流水线传输,在一个 TCP 连接中可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟。在 HTTP1.1 中默认开启 Connection: Keep-Alive,一定程度上弥补了 HTTP1.0 的缺点 -
缓存处理
在 HTTP1.0 中主要使用 Expires、Last-Modified、If-Modified-Since 头部字段来作为缓存判断的标准
在 HTTP1.1 中增加了 Cache-Control、Etag、If-None-Match、If-Match 等头部字段来提供可选的更多的缓存策略 -
带宽优化及网络连接的使用
HTTP1.0中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了。
HTTP1.1 中引入了 Range 头部字段,它允许只请求资源的某个部分,即返回状态码是 206 -
Host头处理
在 HTTP1.0 中认为每台服务器绑定一个唯一的 IP 地址,因此,请求消息中的 URL 并没有传递主机名。但随着虚拟技术的发展,在一台物理设备上可以存在多台虚拟主机,并且他们共享同一 IP 地址 。在 HTTP1.1 的请求消息和响应消息中都应支持 HOST 头域,且请求消息中没有 HOST 头域会报一个错误。 -
错误通知的管理
HTTP1.1 中新增了 24 个错误状态码,如 409 表示请求的资源与资源的当前状态发生冲突;410表示服务器上的某个资源被永久性删除。
http2.0
- 多路复用,如上
- 在 1.1 中消息体一般都会经过gzip压缩或者本身传输的就是压缩过后的二进制文件,而消息头部是以文本进行传输的。但是在2.0中对消息头部进行了压缩。
- 服务器推送
服务端推送是一种在客户端请求之前发送数据的机制。
在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始,然后在它解析和评估页面的时候,增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求,网络经常是空闲的和未充分使用的。
为了改善延迟,HTTP2.0引入了server push,它允许服务端推送资源给浏览器,在浏览器明确地请求之前,免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源,不用再通过网络。
HTTP建立持久连接的意义
在 HTTP1.0 中每发送一次请求都要重新建立 TCP 连接并且关闭连接。这样做是很耗费时间的。而在HTTP1.1 中默认开启长连接,一次TCP连接可以发送多个HTTP请求,避免了重复建立释放连接的开销,加速了数据的传输,节省了时间和带宽。
那么长连接什么时候会释放呢?
客户端的长连接不可能一直拿着,会有一个超时时间,服务器会告诉客户端超时时间,譬如:
Access-Control-Allow-Origin: http://mall.sillywa.com
Connection: keep-alive
Content-Length: 43574
Content-Type: application/json; charset=utf-8
Date: Wed, 03 Mar 2021 07:34:49 GMT
Keep-Alive: timeout=5
Vary: Origin
Keep-Alive: timeout=5 表示这个 TCP 通道可以保持 5s。另外还可能有 max=xxx,表示这个长连接最多接受xxx次请求就断开。对于客户端来说,如果服务端没有告诉是客户端超时时间也没关系,服务端可能主动发起四次挥手断开TCP连接,客户端就能够知道该TCP连接已经无效。
长连接数据传送完成识别:
- 判断传输的数据是否达到了 Content-Length 指示的大小
- 没有 Content-Length,由于数据是分块传输的,这时候就要根据块的编码来判断了,最后一个一个编码的数据是一个空块,表明本次传输结束
TCP和UDP可以共用一个端口号码?
可以,操作系统有能力根据接受的报文的IP字段里面的协议部分判断这个报文是什么报文。使用netstat -an自己看看就知道了,IP数据包首部有个叫做协议的字段,指出了上层协议是TCP还是UDP还是其他P。
协议字段(报头检验和前面那个),其值为6,则为TCP;
其值为17,则为UDP。
跨域问题
同源策略
同源:协议、域名、端口号必须完全相同
跨域的解决方法
1-jsonp
完美解决在测试或者开发中获取不同域下的数据,用户传递一个callback参数给服务端,然后服务端返回数据时会将这个callback
参数作为函数名来包裹住JSON数据,这样客户端就可以随意定制自己的函数来自动处理返回数据了。简单来说数据的格式没有发生
很大变化
- JSONP的优点是:它不像XMLHttpRequest对象实现的Ajax请求那样受到同源策略的限制;它的兼容性更好,在更加古老的浏览器中都 可以运行,不需要XMLHttpRequest或ActiveX的支持;并且在请求完毕后可以通过调用callback的方式回传结果。
- 缺点 不能接受http状态码、不能使用post提交数据、不能发送和接受http头、不能设置同步调用(默认为异步)
1.防止callback参数意外截断js代码,特殊字符单引号双引号,换行符存在风险.
2.防止callback参数恶意添加script标签,造成xss漏洞
3.防止跨域请求滥用,阻止非法站点恶意调用
2-cros同源策略
cookie和session
cdn加速原理
当用户访问使用CDN服务的网站时,本地DNS服务器通过CNAME方式将最终域名请求重定向到CDN服务。CDN通过一组预先定义好的策略(如内容类型、地理区域、网络负载状况等),将当时能够最快响应用户的CDN节点IP地址提供给用户,使用户可以以最快的速度获得网站内容。使用CDN后的HTTP请求处理流程如下
DNS
- 当客户机提出查询请求时,首先在本地计算机的缓存中查找,如果在本地无法查询信息,则将查询请求发给DNS服务器
- 首先客户机将域名查询请求发送到本地DNS服务器,当本地DNS服务器接到查询后,首先在该服务器管理的区域的记录中查找,如果找到该记录,则进行此记录进行解析,如果没有区域信息可以满足查询要求,服务器在本地缓存中查找
- 如果本地服务器不能在本地找到客户机查询的信息,将客户机请求发送到根域名DNS服务器
- 根域名服务器负责解析客户机请求的根域名部分,它将包含下一级域名信息的DNS服务器地址地址,返回给客户机的DNS服务器地址
- 客户机的DNS服务器利用根域名服务器解析的地址访问下一级DNS服务器,得到再下一级域名的DNS服务器地址
- 按照上述递归方法逐级接近查询目标,最后在有目标域名的DNS服务器上找到相应IP地址信息
- 客户机的本地DNS服务器将递归查询结构返回客户机
- 客户机利用从本地DNS服务器查询得到的IP访问目标主机,就完成了一个解析过程
- 同时客户机本地DNS服务器更新其缓存表,客户机也更新期缓存表,方便以后查询