浏览器请求网页的过程
- 敲下回车,首先对网址进行 DNS 解析,把网址转为 IP 地址
- TCP/IP 三次握手,建立以后才能开始 HTTP 请求
- 浏览器得到 HTML 代码,浏览器再解析并下载其中的静态资源渲染页面
- 四次挥手,中断连接
- TCP/IP 是一种长连接,过程完了以后需要客户端 or 服务器发起断开连接请求
URI
- 资源标识的总称是:URI(统一资源标志符)(Uniform Resource Identifier)
- 用来唯一的标识一个资源
- 具体定位某个资源的位置的时候叫:URL(统一资源定位符)(Uniform Resource Locator)
- URL 可以用来标识一个资源,而且还指明了如何定位这个资源
- 用地址定义一个资源
- 资源叫什么,名称是什么的时候叫:URN(统一资源名称)(Uniform Resource Name)
- 即通过名字来表示资源的
- 用名称定位一个资源
- URL肯定是一个URl,URI并不一定是URL,也有可能是URN
举例
客户端和服务端
C/S 和 B/S 架构
域名
什么是域名
- 相当于访问互联网某一户人家的地址
- 域名与服务器绑定以后,域名与服务器对应的 IP 是映射关系
- www.jd.com -> 111.13.28.118
- 域名比 IP 更方便用户记忆
- IP 可以对应多个域名,所以不同的域名可以访问一个或多个WEB网页
购买及解析
购买域名及备案
- 购买:阿里云、万网
- 备案域名:阿里云备案管理
- 解析域名:阿里云后台展示
- 解析就是将域名与服务器 IP 映射的过程,由 DNS 服务器来完成
- A记录:Address. 域名与Ip对应的记录,将域名指向到服务器上
- CNAME记录:别名记录,将多个名字映射到另一个域名(展示七牛云)
A 记录的配置需要在服务器配置虚拟主机,而 CNAME 不用,因为本质是访问别人的服务器****
域名分类
域名级别
- 顶级域名(一级域名):jsplusplus.com
- 二级域名:www.jsplusplus.com 、study.jsplusplus.com
- 三级域名:qianduan.study.jsplusplus.com
DNS
- DNS:Domain Name Server 域名服务器
- 作用:转换 域名与对应ip 的服务器,保存了一张它们的对应的表
- 一个域名 对应 一个ip
- 一个ip 可以对应 多个域名
- DNS就类似下面这张表
DNS 解析
- 输入 www.xxx.com
- 客户端询问 DNS本地服务器 这个域名的 IP 是多少
- DNS本地服务器:就是网络运营商(电信、移动)。它们有自己的DNS服务器
- 如果 DNS本地服务器 的缓存中有,则直接把IP返回
- 如果 DNS本地服务器 没有此域名对应的IP,则会访问 根服务器 ,询问域名对应的IP是多少
- 根服务器会告诉说,我这没有(因为根服务器存的很少,只有1k多条),你得在 .com域服务器 中找,接着把 .com域服务器 IP 地址给到 DNS本地服务器,DNS本地服务器会缓存此IP地址,下次就直接缓存中找
- DNS本地服务器询问 .com域服务器 后,.com域服务器也说没查到(存的也很少,和根服务器一样,一般做管理用的),会告诉你说你去找 xxx.com域服务器吧
- xxx.com域服务器是xxx.com域名的总服务器 IP,并不是 xxx.com域名 本身的 IP
- 然后 DNS本地服务器 就去找 xxx.com 域服务器,xxx.com 域服务器就去找 xxx.com 这个域名的 IP 地址,返回给 DNS本地服务器
- 最后 DNS本地服务器 把这个 xxx.com 域名的 IP 写入缓存,再返回给浏览器,转换成 IP 地址
- 这个时候浏览器就拿到了 IP 地址
IP
- 英文:Internet Protocol Address
- 中文:互联网协议地址、IP 地址
- 作用:分配给用户上网使用的互联网协议
- 分类:IPv4 IPv6 其他
- IPv4:4组,十进制
- IPv6:8组,十六进制
- 形式:192.168.0.1(长度32位(4个字节),十进制表示) (IPv4)
IP 端口号 PORT
- 类比
- IP: 上海市浦东新区川沙新镇、 域名:上海迪士尼乐园、 端口:乐园海盗船的入口
- Ip地址:上海迪斯尼乐园的地址
- IPv4 或 IPv6
- 端口号:乐园中的不同游乐设施
- 80、 443
- 解释
- 找到一个 IP 就像找到了乐园的地址,你就可以到乐园,相当于可以访问到 IP 所对应的服务器,IP 加端口号,相当于到乐园去玩儿不同的项目,每个项目其实就是一个端口号。
- 总结
- 每一个端口对应的是一个服务器的一个业务,访问一个服务器的不同端口相当于访问不同的业务。
- 端口号范围
- 0-65535
- 默认情况下
- http:80
- https:443
- ftp:20、21
TCP
- TCP: Transmission Control Protocol 传输控制协议
- 特点:面向连接(收发数据前,必须建立可靠的连接)
- 建立连接基础:三次握手
- 应用场景:数据必须准确无误的收发
- HTTP请求、FTP文件传输、邮件收发
- 优点:速度慢、稳定、重传机制、拥塞控制机制、断开连接
- 缺点:效率低、占用资源、容易被攻击(三次握手 → DOS、 DDOS攻击)
- TCP/IP协议组:提供点对点的连接机制,制定了数据封装、定址、传输、路由、数据接收的标准。
- 只要是传数据,不管收发,都得建立可靠的连接
TCP 连接的前奏
TCP 三次握手
- 客户端:发送连接请求(喂,听得到吗?)
- 发送包 序号SYN J
- 服务端:我收到了请求,确认可以连接(听得到,你听得到我吗)
- 发送包 序号SYN K 和 确认包 序号ACK J + 1
- 客户端:收到服务端确认信息,确认连接建立(听到了,我们可以说话了)
- 发送包 序号ACK K + 1
- 发送序号是上一次的确认序号
- 确认序号是上一次发送信号+1
总结
- 第一次握手
- 客户端向服务器发送
SYN
标志位(序号是J
),并进入SYN_SEND
状态(等待服务器确认状态)。
- 客户端向服务器发送
- 第二次握手
- 服务器收到来自客户端的
SYN J
,服务端会确认该数据包己收到并发送ACK
标志位(序号是J+1
)和SYN
标志位(序号是K
),服务器进入SYN_RECV
(请求接收并等待客户端确认状态)。
- 服务器收到来自客户端的
- 第三次握手
- 客户端进入连接建立状态后,向服务器发送
ACK
标志位(序号是K+1
) 确认客户端已收到建立连接确认,服务器收到ACK
标志位后,服务端进入连接已建立状态。
- 客户端进入连接建立状态后,向服务器发送
资源
https://github.com/jawil/blog/issues/14
UDP
UDP: User Data Protocol 用户数据报协议
- 特点
- 面向无连接(不可靠的协议,无状态传输机制)
- 无连接信息发送机制
- 应用场景
- 无需确保通讯质量且要求速度快、无需确保信息完整
- 消息收发、语音通话、直播 (QQ)
- 优点
- 安全、快速、漏洞少(UDP flood攻击)
- 缺点
- 不可靠、不稳定、容易丢包
- 总结
- 只要目的源地址、端口号、地址、端口号确定,则可以直接发送信息报文, 但不能保证一定能收到或收到完整的数据。
TCP 和 UDP 的区别
- TCP 是面向连接的,UDP 是无连接的即发送数据前不需要先建立链接。
- TCP 提供可靠的服务。也就是说,通过 TCP 连接传送的数据,无差错,不丢失,不重复,且按序到达; UDP 尽最大努力交付,即不保证可靠交付。 并且因为 TCP 可靠,面向连接,不会丢失数据因此适合大数据量的交换。
- TCP 是面向字节流,UDP 面向报文,并且网络出现拥塞不会使得发送速率降低(因此会出现丢包,对实时的应用比如IP电话和视频会议等)。
- TCP只能是 1 对 1 的,UDP 支持 1 对 1, 1 对多。
- TCP 的首部较大为 20 字节,而 UDP 只有 8 字节。
- TCP 是面向连接的可靠性传输,而 UDP 是不可靠的。
HTTP 与 HTTPS
- HTTP
- HyperText Transfer Protocol 超文本传输协议
- 定义
- 客户端和服务器端请求和应答的标准,用于从 WEB 服务器传输超文本到本地浏览器的传输协议
- HTTP请求
- 按照协议规则先向 WEB 服务器发送的将超文本传输到本地浏览器的请求
- HTTPS
- HyperText Transfer Protocol Secure 超文本传输安全协议
- 定义
- HTTP 的安全版(安全基础是 SSL/TLS)
- 使用 SSL/TLS 给 HTTP 套了个安全套,使其更安全
- 可以理解为 HTTPS 就是在 HTTP 的基础上穿了两件外套,分别是 SSL 和 TLS
- SSL: Secure Sockets Layer 安全套接层
- TLS: Transport Layer Security 传输层安全
- 为网络通信提供安全及数据完整性的一种安全协议,对网络连接进行加密
区别
- HTTP是不安全的(监听和中间人攻击等手段,获取网站账户信息和敏感信息)
- HTTPS可防止被攻击
- HTTP 协议的传输内容都是明文,直接在 TCP 连接上运行,客户端和服务器都无法验证对方身份
- HTTPS 协议的传输内容都被 SSL/TLS 加密,且运行在 SSL/TLS 上, SSL/TLS 运行在 TPC 连接上,所以数据传输是安全的
HTTP 报文
前言
- HTTP 基于 TCP/IP 通讯协议 来 传递数据
- HTTP 基于 客户端/服务端 (C/S) 架构模型
- 通过一个可靠的连接来交换信息,是一个无状态的请求/响应协议
- 无状态的协议(无状态:没有记忆的,不知道断开连接后的上一次连接交换过哪些信息的意思。打比方:抛硬币上一次正面在上并不会影响下一次正面在上的概率)
- 限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间
- 只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过 HTTP 发送。客户端以及服务器指定使用适合的 MIME-type 内容类型
- MIME-type 多用途互联网传输扩展类型
- Multipurpose Internet Mail Extensions type
报文类似 chrome 中的 network 的 req 和 res,但并不是下面截图,因为下面截图是浏览器整理报文之后呈现的一种格式:
报文
要背👇🏻
报文的组成部分:
- 对报文进行描述的起始行
- 包含属性的首部/头部 (header)
- 包含数据的主体 (body)(可选项)
- request header 请求头
- request body 请求体
- response header 响应头
- response body 响应体
报文基本格式
GENERAL(通用报)
REQUEST HEADERS(请求头)
RESPONSE HEADERS (响应报)
请求体
响应体
请求方式
了解
8 种请求方式(HTTP1)
- GET/POST
- OPTIONS:返回服务器针对特定资源所支持的 HTTP 请求方法
- HEAD:返回与GET请求相一致的响应,响应体被返回
- PUT:向指定资源位置上传其最新内容(form表单不支持)
- DELETE: 请求服务器删除 Request-URI 所标识的资源(form表单不支持)
- TRACE:回显服务器收到的请求,主要用于测试或诊断
- CONNECT:连接改为管道方式的代理服务器
重要
- put:上传资源,form表单不支持、提交即存储的原则(无验证机制,安全漏洞)、需配置服务器支持put方式转发打给后端操作。
- delete:删除资源,form表单不支持、提交即删除的原则(无验证机制,安全漏洞)、需配置服务器支持put方式转发打给后端操作。
- post:修改资源
- get:获取资源
- 对应的就是数据的增、删、改、查
- 4种不同的请求方式是为了分清楚不同请求的目的,但是并不代表用了 post 就一定要修改数据,用 get 就不能修改资源。
- 一般不用 put、delete 是因为 form 表单不支持
- post 和 put 有什么区别:
- put 一般用来上传资源,post 一般用于修改资源
- put form 表单不支持,提交就存储,无验证机制,有安全漏洞,一般服务器不支持,需要配置才行
GET / POST
区别(必背)
- POST更安全
- 不作为url一部分,不会被缓存,不在浏览器记录中,不保存再服务器日志中
- POST能发送更大数据
- POST能发送更多数据类型,而GET只能是ASCII码字符
- POST比GET慢
- 过程慢
- get能进行数据缓存,post不行(e.g. 例如下载图片,get的能缓存)
- post不能进行管道化传输
get 和 post 过程(也要背)
- 管道化持久连接的弊端:
- 一旦传输过程中出现断开,需要重新开始一次队列任务。如果是支付的请求,就有可能出现钱付了,突然传输断了,导致又走一遍支付流程
幂等
- 一个数字,它的几次方等于它自己,这叫做幂等。0,1它们俩的n次方都等于它们自己
- 幂等性:获取数据,才有幂等性。因为不会数据或状态做修改。返回结果一样
- 从http请求来看,get请求必须遵守幂等性,不允许增删改
- 管道化持久连接不支持非幂等性请求
GET 请求传参长度的误区
误区:我们经常说 get 请求参数的大小存在限制,而 post 请求的参数大小是无限制的。
实际上 HTTP 协议从未规定 GET/POST 的请求长度限制是多少。对 GET 请求参数的限制是来源与浏览器或 WEB 服务器,浏览器或 WEB 服务器限制了URL 的长度。为了明确这个概念,我们必须再次强调下面几点:
- HTTP 协议 未规定 GET 和 POST 的长度限制
- GET 的最大长度显示是因为浏览器和 WEB 服务器限制了 URL 的长度
- 不同的浏览器和 WEB 服务器,限制的最大长度不一样
- 要支持 IE,则最大长度为 2083 byte,若只支持 Chrome,则最大长度 8182 byte
HTTP 状态码
一、是什么
HTTP状态码(英语:HTTP Status Code),用以表示网页服务器超文本传输协议响应状态的3位数字代码 它由 RFC 2616规范定义的,并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774与 RFC 4918等规范扩展 简单来讲,http状态码的作用是服务器告诉客户端当前请求响应的状态,通过状态码就能判断和分析服务器的运行状态
二、分类
状态码第一位数字决定了不同的响应状态,有如下:
- 1 表示消息
- 2 表示成功
- 3 表示重定向
- 4 表示请求错误
- 5 表示服务器错误
1xx
代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束
常见的有:
- 100(客户端继续发送请求,这是临时响应):这个临时响应是用来通知客户端它的部分请求已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求的剩余部分,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应
- 101:服务器根据客户端的请求切换协议,主要用于websocket或http2升级
2xx
代表请求已成功被服务器接收、理解、并接受
常见的有:
- 200(成功):请求已成功,请求所希望的响应头或数据体将随此响应返回
- 201(已创建):请求成功并且服务器创建了新的资源
- 202(已创建):服务器已经接收请求,但尚未处理
- 203(非授权信息):服务器已成功处理请求,但返回的信息可能来自另一来源
- 204(无内容):服务器成功处理请求,但没有返回任何内容
- 205(重置内容):服务器成功处理请求,但没有返回任何内容
- 206(部分内容):服务器成功处理了部分请求
3xx
表示要完成请求,需要进一步操作。 通常,这些状态代码用来重定向
常见的有:
- 300(多种选择):针对请求,服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作,或提供操作列表供请求者选择
- 301(永久移动):请求的网页已永久移动到新位置。 服务器返回此响应(对 GET 或 HEAD 请求的响应)时,会自动将请求者转到新位置
- 302(临时移动): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
- 303(查看其他位置):请求者应当对不同的位置使用单独的 GET 请求来检索响应时,服务器返回此代码
- 304(协商缓存):查看浏览器的 if-none-match 和 if-modified-since 和 服务器 ETag 和 last-modified 是否一直,一致就返回 304 响应头告知浏览器使用本地缓存
- 305 (使用代理): 请求者只能使用代理访问请求的网页。 如果服务器返回此响应,还表示请求者应使用代理
- 307 (临时重定向): 服务器目前从不同位置的网页响应请求,但请求者应继续使用原有位置来进行以后的请求
4xx
代表了客户端看起来可能发生了错误,妨碍了服务器的处理
常见的有:
- 400(错误请求): 服务器不理解请求的语法
- 401(未授权): 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
- 403(禁止): 服务器拒绝请求
- 404(未找到): 服务器找不到请求的网页
- 405(方法禁用): 禁用请求中指定的方法
- 406(不接受): 无法使用请求的内容特性响应请求的网页
- 407(需要代理授权): 此状态代码与 401(未授权)类似,但指定请求者应当授权使用代理
- 408(请求超时): 服务器等候请求时发生超时
5xx
表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生
常见的有:
- 500(服务器内部错误):服务器遇到错误,无法完成请求
- 501(尚未实施):服务器不具备完成请求的功能。 例如,服务器无法识别请求方法时可能会返回此代码
- 502(错误网关): 服务器作为网关或代理,从上游服务器收到无效响应
- 503(服务不可用): 服务器目前无法使用(由于超载或停机维护)
- 504(网关超时): 服务器作为网关或代理,但是没有及时从上游服务器收到请求
- 505(HTTP 版本不受支持): 服务器不支持请求中所用的 HTTP 协议版本
三、适用场景
下面给出一些状态码的适用场景:
- 100:客户端在发送POST数据给服务器前,征询服务器情况,看服务器是否处理POST的数据,如果不处理,客户端则不上传POST数据,如果处理,则POST上传数据。常用于POST大数据传输
- 206:一般用来做断点续传,或者是视频文件等大文件的加载
- 301:永久重定向会缓存。新域名替换旧域名,旧的域名不再使用时,用户访问旧域名时用301就重定向到新的域名
- 302:临时重定向不会缓存,常用 于未登陆的用户访问用户中心重定向到登录页面
- 304:协商缓存,告诉客户端有缓存,直接使用缓存中的数据,返回页面的只有头部信息,是没有内容部分
- 400:参数有误,请求无法被服务器识别
- 403:告诉客户端进制访问该站点或者资源,如在外网环境下,然后访问只有内网IP才能访问的时候则返回
- 404:服务器找不到资源时,或者服务器拒绝请求又不想说明理由时
- 503:服务器停机维护时,主动用503响应请求或 nginx 设置限速,超过限速,会返回503
- 504:网关超时
参考文献
- https://zh.wikipedia.org/wiki/HTTP状态码
- https://kebingzao.com/2018/10/05/http-status-code/
- https://vue3js.cn/interview
304 重定向
- 东八区
- 东+,西-(在 GMT 基础上)
- GMT 世界协调时 - 格林威治时间,又叫 UTC 时间。作用:同一时间
- 飞机上的时间,全部是世界协调时,因为飞国外,用本地时间没法用
- 第一次访问index.html
- 响应头 200 OK
- 服务端返回:
- ETag(服务端给index.html文件设置的唯一标识)
- Last-Modified(index.html文件最后一次修改时间)
- 第二次访问index.html
- 客户端请求头发送:
- If-None-Match(第一次服务端返回的 ETag)
- If-Modified-Since(第一次服务端返回的 Last-Modified 时间)
- 服务端拿到客户端发送的内容对比,发现文件并没有改变,所以不再把文件返回一遍,而是返回响应头 304 Not Modified,告知浏览器从本地缓存里取 ETag为 "144-"开头的这个文件
- 客户端请求头发送:
- 服务端后来修改了index.html,客户端第三次访问index.html
- 客户端请求头发送:
- If-None-Match
- If-Modified-Since
- 服务端发现文件修改后的 ETag 和 Last-Modified 和客户端请求的不一致了
- 返回响应头 200 OK
- 响应头发送新的 ETag 和 新的 Last-Modified
- 客户端请求头发送:
302 重定向
- 客户端访问的A页面
- 服务端A页面代码内部跳转到B页面
- 返回 302 Found
404 页面错误
403 请求被拒
- 服务器关闭
- 无权限访问
500 服务器内部错误
503 服务暂时不可用
ACCEPT & Content-Type
ACCEPT - 浏览器给服务器说的
客户端希望或者可以接收的数据类型
q - 相对品质因子,权重
- 默认1
- 0提示服务器该内容类型不被浏览器接受
- Accept中,
,
逗号代表分隔,而不是;
。像下面text/html,
相当于text/html;q=1
q=1是默认的
Content-Type - 服务器对浏览器说的
Content-Encoding - 接受的资源编码格式(压缩格式)
附件
浏览器缓存
Pragma
- 响应头里面的
- 指示浏览器不要拿缓存的副本,而是每次都从服务端获取
- 但这不代表浏览器不会缓存副本,仅仅是不使用本地缓存
- pragma是 http1.0字段;在http1.1中 cache-control 替代了 pragma
- cache-control 和 pragma 同时存在时,cache-control 优先级更高
- http向下兼容:新的兼容旧的字段,旧的也能用
Cache-Control
- 用来控制缓存的
- 是响应头里边的
- no-cache 让浏览器忽略缓存,而不是让浏览器不缓存。(浏览器依旧缓存)
- 可以在客户端存储资源,每次都必须去服务端做新鲜度校验,来决定从服务端获取新的资源(200)还是使用客户端缓存(304)。也就是所谓的协商缓存。
- no-store 这个才是不让浏览器缓存
- max-age 从请求开始算,到过期时间之间的秒数
- public 谁都能缓存,代理服务器也行
- private 代理服务器不能缓存
Expires
- 一般存在于响应头
- 优先级没有 cache-control 高
浏览器缓存图解
- 一般图片,js类都 from memory cache
- css之类的 from disk cache
强缓存 与 协商缓存
- expires 或 cache-control 没过期,走强制缓存
- if-none-match 和 if-modified-since 与 ETag 和 last-modified 匹配,走协商缓存 304
更多
https://juejin.cn/post/6844903747357769742
长短连接
短连接
长连接
Content-Length
- 描述HTTP消息实体的传输长度
- get请求中,只有响应头带 content-length
- post请求中,请求头响应头中都有
响应头 content-length
6是因为返回的123456长度
请求头 content-length
33是因为 post 请求最终发送的是 username=superatc&password=123456
。
REFERER
- 记录从哪儿进来的
- e.g. google搜索腾讯课堂,点击链接进腾讯课堂后,referer显示的就是 https://www.google.com
- referer原本叫referrer,只是写错了。后边沿用不改了
- 应用:
- 分销的渠道来源,e.g. 比如点击某个页面进来,才算这个渠道进来的客户防视频盗链,判断referer是不是自己的域名或ip
- 上面设置后,从设置的页面跳转的链接里才会生效
面试问防盗链
Q:你对防盗链这个事儿怎么看
A:防盗链一般针对的是视频之类的比较敏感的资源,需要防盗链处理。当然100%防盗链是不可能的。但我们可以借助一些机制来处理。
比如说 referer 防盗链。我们可以在服务器获取资源之前来判断 referer 是不是我所信赖的来源域名,如果不是我就拦截这次请求,如果是我将返回资源给它
举个例子,比如在七牛云上边,每一个我们所绑定的域名都可以设置防盗链配置,在里边设置白名单黑名单。如果七牛检测到是白名单的就返回,否则不返回资源
或者
时间戳防盗链
通过时间戳和签名规则来形成一个秘钥,这个秘钥是跟在资源地址的后面的。把这个资源和秘钥一起发给服务器,服务器会鉴别这个签名对不对,如果对,再去检查过期没有。如果签名对而且没过期,就返回资源;否则不返回
HTTP 版本
- 双工模式:客户端能同时发送多个请求,服务端也能同时处理多个请求
- 头信息压缩机制:http是无状态的,每次请求都发头信息,所以2.0新增了压缩拓信息机制
- 多工:一次性发多个请求给服务端,如果某个请求响应慢,会先处理一部分放哪儿,再先响应快的请求,把它们先返回,最后再处理响应慢的那个,最后再返回
总结 http1/http2 区别
- 多路复用
- 单连接多资源的方式,减少服务端的链接压力,内存占用更少,连接吞吐量更大;由于减少TCP 慢启动时间,提高传输的速度
- 头信息压缩
- 头信息之前不被压缩,纯文本形式传输;现在为了减少流量浪费,对头信息进行压缩
- 服务器推送
- 允许服务端推送资源给浏览器,在浏览器明确地请求之前。一个服务器经常知道一个页面需要很多附加资源,在它响应浏览器第一个请求的时候,可以开始推送这些资源。这允许服务端去完全充分地利用一个可能空闲的网络,改善页面加载时间。
关闭 TCP 连接
四次挥手
- ACK: acknowledge
- 客户端发送连接中断请求,包名就是1(FIN=1),序列号是u(seq=u),发送后客户端处于 FIN-WAIT-1 状态
- 目的就是请求服务端关闭连接
- 服务端确认这个FIN包,ack=u + 1(表示我看过了,我确认好了),发的是个确认包,这个包的总体叫大 ACK包(ACK=1),序列号是v(seq=v),跟小ack不一样。此时服务端处于CLOSE-WAIT,也就是关闭TCP的等待状态
- 客户端接收到服务端发送的确认包后,FIN-WAIT-1状态才结束。然后客户端进入 FIN-WAIT-2 阶段(此阶段不会再发请求了,但可以接受响应)
- 服务端检查自己还有没有数据要传输,如果有接着传输,如果没有就发一个确认包(FIN=1 ACK=1 seq=w ack=u+1),表示我真的没有数据要发送了,可以关闭了,此时服务端进入 LAST-ACK 状态
- 客户端接收到服务端发送的确认包,进入 TIME-WAIT 阶段。并主动发送一个确认包给服务端(ACK=1,seq=u+1【针对第一次自己发的seq=u】 ack=w+1【针对上一次服务端的序列号seq=w】)
- 服务端接收到了这个包,就变成 CLOSE 状态,不再发送给客户端任何信息
- 客户端由于接收不到服务端发送的信息了,所以会等待2MSL,等待一段时间,发现不会再有数据了,就自己变成 CLOSE 状态
- 2MSL作用(TIME-WAIT的意义):假如服务端没接收到客户端发送的第四次挥手,就会认为自己的第三次挥手客户端没收到,那么服务端就会重新发送第三次挥手,接着客户端收到第三次挥手,再发送第四次挥手。(为什么这个等待MSL过程不在服务端而在客户端,是因为服务端不会再第五次挥手了,所以只有客户端等待才行)。只要服务端重新发送了第三次挥手,客户端的MSL就会重新计时
总结
保活计时器
同源策略
介绍
解释报错现象
何为同源
同源策略的目的
- 减少服务器压力
- 加强数据安全
解决方案
Access-Control-Allow-Origin
避免同源策略
- 网页图片链接可以不同源
- 加载 cdn link 可以不同源
减少 HTTP 请求的方法
从 url 回车 ——> 页面呈现
- url输入,回车
- DNS解析:解析 url,变成 相应服务器的IP地址/代理服务器的IP地址
- 浏览器向相应服务器发起TCP/IP连接请求
- 在此过程中发生了三次握手
- 建立TCP/IP连接
- 浏览器网络发起HTTP请求
- 等待 服务端响应 waiting
- 下载HTML资源
- 解析HTML
- 遇到HTML里的资源,再次发起HTTP请求,下载资源
- 四次挥手
- 时间线
- 呈现页面
其中 5-9 最耗时间(http请求资源部分)
解决方法
- CSS雪碧图,能做雪碧图就做雪碧图(小图片合并大图片,设置 background-position 定位)。可能经常更新的图片不要用雪碧图
- 装饰性东西
- 边框
- 纹理
- 小的图标
- base64编码(小于多大的图片用base64编码,减少http请求)所以小的图标
- 缺点:
- 数据量增加了
- 不一定加载快,复杂、大的图片解析base64花的时间比http请求回来还长
- 合并脚本与样式表代码
- 把部分JS/CSS合并到html中
- 配置多个域名(避免一台服务器多个请求下载变慢) 和 CDN加速服务(接收并发请求,本身的速度也快)
- 你用你的域名,在第三方服务器上进行解析,从而生成CDN加速域名
- 尽量使用浏览器的缓存机制
- img map 合并一张图片(同样 background-position 去定位)
- 缺点:
Comments NOTHING