计算机网络基础
计算机网络是指容许节点分享资源数字电信网络.在电脑网络, 电脑设备会透过节点间的连接互相交换数据.传输介质可分为有线和无线两类. 用于创建、路由及终止数据传输的电脑网络设备即为网络节点.
网络层次
为了是不同的计算机厂家生产的计算机能够互相通信, 以便在更大范围建立计算机网络, 国际标准化组织提出 “开放系统互联网参考模型 ”, 即 OSI/RM.
物理层
物理层为撒谎个疗程协议提供了一个传输数据的可靠无力媒介, 它确保了原始数据可在各种无力媒体上传输. 物理层有两个重要的设备中继器和集成器
数据链路层
数据链路层在物理层的基础上向网络层提供服务, 其最基本的服务是将源自网络层的数据可靠地传输到相邻节点的目标机网络层. 该层的作用包括 物理地址寻址、数据的成帧、流量控制、数据的检查、重发等
帧是数据链路层的传送单位, 以以太网为协议, 同样有两个重要的设备网桥和交换机.
网络层
网络层主要实现两个系统间的数据透明传送, 具体包括寻址、路由选择、连接建立、保持和终止等, 它提供的服务使传输层不需要了解网络中的数据传输和交换技术.
IP协议位于网络层. IP 协议仅仅提供不可靠、无连接的传送服务. IP 协议的主要功能包括无连接数据报文传呼、数据报文路由选择和差错控制. 基本数据单位为 IP 数据报.
与 IP 协议配套使用实现其功能的还有地址解析协议 ARP、逆地址解析协议 RARP 、因特网报文协议 ICMP、因特网组管理协议 IGMP.
这一层的主要设备是路由器.
传输层
传输层负责将上层数据分段并提供端到端的、可靠的或不可靠的传输, 此外, 传输层还要处理端到端的差错控制和流量控制问题. 传输层的任务是根据通信子网的特性, 最佳的利用网络资源,为两个系统的会话层之间, 提供建立、维护和取消传输连接的功能.
这一层的消息传送的协议为端或报文. 网络层只是根据网路地址将源节点发出的数据包传送到目标节点, 而传输层则负责将数据可靠地传送到相应的端口.
会话层
负责建立、管理、终止进程间的会话.会话层还利用在数据插入校验点来实现数据的同步.
表示层
表示层对上层数据或信息进行交换以保证一个主机应用层信息可以被另一个主机的应用程序理解. 表示层的数据转换包括数据的加密、压缩、格式转换等.
应用层
为操作系统或网络应用程序提供访问网络服务的接口.
HTTP协议(超文本传输协议)、rpc 协议、FTP 协议、Telnet 协议、DNS 域名解析协议、SMTP(邮件传送协议)、POP3 协议(邮局协议)
IP(Internet Protocol)协议
IP 协议是用于分组交换数据的一种协议.
IP 协议是在 TCP/IP 协议族的主要协议, 任务仅仅是根据源主机和目的主机的地址来传送数据. 为此目的, IP 定义了寻址方法和数据报的封装结构.第一个主要的架构版本是 IPv4, 目前仍然是广泛使用的互联网协议. 但目前世界各地已在积极部署 IPv6.
IP 地址 = 网络号段 + 主机号段 = 网络号段 + ( 子网号段 + 子网主机号段 )
IPv4 可以被写作任何表示一个 32 位整数值的形式, 但通常使用点分十进制的形式表示.
分类
A 类地址以 0 开头, 第一个直接作为网络号,地址范围 0.0.0.0 ~ 127.255.255.255
B 类地址以 10 开头,前两个字节作为网络号, 地址范围 128.0.0.0 ~ 191.255.255.255
C 类地址以 110 开头, 前三个字节作为网络号, 地址范围 192.0.0.0 ~ 223.255.255.255
D 类地址以 1110 开头, 地址范围 224.0.0.0 ~ 139.255.255.255, D 类地址作为多播地址, 用于一对多通信
E 类地址以 1111 开头, 地址范围 240.0.0.0 ~ 255.255.255.255, E 类地址为保留地址.
只有 A、B、C 有网络号和主机号之分, D 类和 E 类没有划分网络号与主机号.
网络地址
IP 地址有网络号(包括子网号)和主机号构成, 网络地址的主机号全为 0. 网络地址代表着整个网络.
广播地址
广播地址通常也称为直接广播地址, 是为了区分受限广播地址.
广播地址与网络地址的主机号正好相反, 广播地址中, 主机号全为 1. 当向某个网络的广播地址发送消息时, 该网络内的所有主机都能收到这一消息.
多播地址
多播用于将包发送给特定组内的所有主机.由于其直接使用 IP 地址, 因此也不存在可靠传输
相比于广播多播可以穿透路由器, 又可以实现只给必要的组发送数据包
255.255.255.255
该 IP 地址指的是受限的广播地址.
受限广播地址与一般广播地址的区别在于, 受限广播地址只能用于本地网络, 路由器不会转发以受限广播为目的的地址的分组; 一般广播地址既可以在本地广播也可以跨网段广播. 例如: 主机 192.168.1.1/30 上的直接广播数据包后, 另一个网段 192.168.1.5/30 也能收到该数据报.若发送受限广播数据报, 则不能收到.
一般广播地址能够通过某些(非所有)路由器, 而受限广播地址不能通过.
0.0.0.0
回环地址
127.0.0..0/8 被用作回环地址,回环地址表示本机地址,常用于对本机的测试, 用的最多的是 127.0.0.1 .
ABC 类私有地址
私有地址也叫专用地址, 他们不会在全球使用, 只具有本地意义.
A 类私有地址: 10.0.0.0/8, 范围: 10.0.0.0 ~ 10.255.255.255
B 类私有地址: 172/16.0.0/12, 范围是: 172.16.0.0 ~ 172.31.255.255
C 类私有地址:192.168.0.0/16, 范围是: 192.168.0.0 ~ 192.168.255.255
子网掩码
现在一个 IP 地址的网络标识和主机已不再受限于该地址的类别, 而是由一个叫做子网掩码的识别码通过子网网络地址细分出比 A 类、B 类、C 类更细小的网络.
子网掩码用二进制表示也是一个 32 位数字.它对应 IP 地址网络标识部分的位全为 1, 对应 IP 地址的自己标识部分则全为 0. 由此, 一个 IP 地址可以不再受限于自己的类别. 而是可以用这样的子网掩码自由地定位自己的网络标识长度.
IPv6
IP 是为了根本解决 IPv4 地址耗尽的问题而被标准化的网络协议
IPv4 的地址长度是 4 个字节, 即 32 比特位. 而 IPv6 的地址长度则为原来的 4 倍, 即 128 比特. 一般写成 8 个 16 字节.
IP 地址的扩大于路由控制表的聚合
性能提升, 包首部长度采用固定值(40bytes) , 不再采用首部校验码. 简化首部结构, 减轻路由负担.
支持即插即用功能, 即使没有 DHCP 服务器也可以实现自动分配 IP 地址
采用认证与加密功能, 应对伪造 IP 地址的网路安全功能以及防止线路窃听功能
多播、Mobile IP 成为扩展功能.
UDP ( User Datagram Protocol )
用户数据报协议是一个简单的面向数据报的通信协议, 位于 OSI 模型的传输层.
可靠性
由于缺乏可靠性且属于无连接协议, 所以应用程序通常必须容许一些丢失、错误或重复的数据包.
一些应用程序不太需要可靠性机制, 甚至可能会因为引入可靠性而降低性能, 所以它们使用 UDP 这种缺乏可靠性的协议.
UDP 的结构
UDP 报头包括 4 个字段, 每个字段占两个字节.
在 IPv4 中, “来源连接端口” 和 “校验和” 是可选字段. 在 IPv6 这种, 是有来源连接端口是可选字段.
来源端口和目的端口用来标记和接受的应用进程.因为 UDP 不需要应答, 所有端口是可选的, 如果来源端口不用,需要置 0.
报文长度
来源端口之后是笃定长度的以字节为单位的长度域, 用来指定 UDP 包的长度(包括头部和数据包), 最小值为 8bytes. 最大值为 65535bytes. 因为 IPv4 协议传输时, IPv4 的头部信息需要 20bytes, 因此数据的长度不能超过 65507bytes( 65535bytes - 8bytes UDP 报头 - 20bytes IPv4 报头 ).
检验和
校验和字段可以用于发现头部信息和数据中的传输错误. 在 IPv4 中是可选的, 在 IPv6 中是强制的, 如果不使用, 应该置 0.
当 UDP 运行在 IPv4 之上时, 为了能够计算校验和, 需要在 UDP 数据包前面添加一个伪头部. 伪头部包括了 IPv4 头部中的一些信息, 但它并不是发送 IP 数据包时的使用的 IP 数据包的头部,而只是用来计算校验和而已.
当 UDP 运行在 IPv6 上时, 校验和时必须的,任何包含来自 IP 头地址的传输层或其他商城协议, 其校验和计算被修改, 以适应 IPv6 的 128 位 IP 地址.
TCP ( Transmission Control Protocol )
TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议. 在因特网协议族中, TCP 位于 IP 层之上, 应用层之下的中间层.
应用层向 TCP 层发送用于网间传输的、用 8 位字节表示的数据流, 然后 TCP 把数据流分割成适当长度的报文段, 通常受该计算机连接的网络的数据链路层的最大传输但愿的限制, 之后 TCP 把结果包传给 IP 层, 由它来透过网络将包传送给接受端实体的 TCP 层.
TCP 为了保证数据完整性, 就给每个包一个序号, 同时序号也保证了传送到接收端实体的包的按序接受.然后接受端实体对已经成功接收的包发回一个确认信息(ACK), 如果发送端实体在合理的往返延时(RTT)内未收到确认, 那么对应的数据包就被假设为已丢失并进行重传.
TCP 是一个校验和函数来检验数据是否有错误, 在发送和接收时都要计算校验和.
TCP 协议的运行可划分为三个阶段: 连接创建、数据传送和连接终止. 操作系统将 TCP 连接抽象为套接字表示的本地端点, 作为编程接口给程序使用.
连接创建
TCP 三次握手过程创建一个连接. 在连接创建过程中, 很多参数要被初始化, 例如序号要被促使刷以保证按序传输和连接的强壮性.
服务端执行了 listen 函数后, 在服务器上创建起两个队列
SYN 队列: 存放完成了二次握手的结果. 队列的长度由 listen 函数的参数 backlog 指定.
ACCEPT 队列: 存放完成三次握手的结果. 队列的长度由 listen 函数的参数 backlog 指定.
三次握手
客户端向服务端发送一个 SYN 包( 通过执行 connect 函数 ), 这个包携带客户端为这个连接请求而设定的随机数 A 作为消息序列号.
服务器收到一个合法的 SYN 包后, 把该包放入 SYN 队列中; 返回一个 SYN/ACK. ACK 的确认码为 A+1, SYN/ACK 包本身携带一个随机数 B.
客户端收到 SYN/ACK 后, 发送一个 ACK 包, 该包的序号被设定为 A+1, 而 ACK 的确认码这为 B+1. 然后客户端的 connect 函数成功返回. 但服务器接收到这个 ACK 包的时候, 把请求帧从 SYN 队列中移出, 放至 ACCEPT 队列中; 这时 accept 函数如果处于阻塞状态, 可以被唤醒, 从 ACCEPT 队列中取出一个 ACK 包, 重新创建一个新的用于双向通信的 sockfd, 并返回.
四次挥手
当一个端点要停止它这一侧的连接时, 就像对方发送 FIN, 对方恢复 ACK 表示确认. 因此关闭连接的过程需要一对 FIN 和 ACK, 分别由两端发出.
看起来 TCP 将两端连接起来了, 但实际上只是两端共同维护了一个状态.
状态编码
LISTEN ( server ): 服务器等待从任意远程 TCP 端口的连接请求.
SYN-SENT ( client ): 客户在发送连接请求后等待匹配的连接请求.
SYN-RECEIVED ( server ): 服务器已经收到并发送同步信号之后等待确认请求.
ESTABLISHED ( server and client ): 服务器与客户端的连接已经建立, 可以互相发送数据.
FIN-WAIT-1 ( server and client ): 服务器或客户端主动关闭端调用 close 函数, 发送 FIN 请求包. 表示本方的数据以全部发送完毕, 等待 TCP 连接另一端的 ACK 确认包或 FIN&ACK 请求包.
FIN-WAIT-2( server and client ): 主动关闭端在 FIN-WAIT-1 的状态下收到 ACK 确认包, 进入等待远程 TCP 连接终止请求的半关闭状态. 此时可以接收数据, 当不再发送数据.
CLOSE_WAIT ( server and client ): 被动关闭端接到 FIN 后, 就发出 ACK 以回应请求, 并进入等待本地银狐的连接终止请求的半关闭状态.
CLOSING (server and client): 在发出 FIN 后, 又收到对方发来的 FIN 后, 进入等待对方的连接终止 FIN 的确认 ACK 状态. 少见.
LAST-WAIT ( server and client ): 被动关闭端全部数据发送之后, 向主动关闭端发送 FIN, 进入等待确认包的状态
TIME-WAIT ( server or client ): 主动关闭端接收到 FIN 后, 就发送 ACK 包, 等待足够的事件以确保被动关闭端收到了终止请求的确认包.
CLOSED (server and client): 连接关闭
TCP 头部
TCP 的头部比 UDP 要复杂的多.
来源连接端口 16 位长度 - 识别发送端连接端口
目的连接端口 16 位长度 - 识别接收端连接端口
序列号 32 位长度
如果含有同步位 SYN , 则此位为最初的序列号; 第一个资料比特的序列号码为本序列号加 1.
如果没有同步位 SYN, 则此序列号为第一资料比特的序列号.
确认号 32 位 - 期望收到的数据的开始序列号, 也即已经收到的数据字节长度加一.
资料偏移 4 位 - 以 4 字节位单位计算出的数据段开始地址的偏移值.
保留位 3 位 - 需要置 0.
标志符 9 位
NS - ECN 显式拥塞通知是对 TCP 的扩展. 它允许拥塞控制的端对端通知而便面丢包. 作为一项可选功能, 如果底层网络设施支持, 则可能被启用 ECN 的两个端点使用. 在 ECN 成功协商的情况下, ECN 感知路由器可以在 IP 头中设置一个标志来代替丢弃数据包.以表明阻塞即将发生.数据的接受端回应发送端的表示, 降低其传输速率,就如同在往常中检测到丢包一样.
CWR - Congestion Window Reduced 减弱拥塞窗口
ECE -
URG - 为 1 表示高优先级数据报,紧急指针字段有效
ACK - 为 1 表示确认号字段有效
PSH - 为 1 表示是带有 PUSH 标志的数据, 指示接收方应尽可能将这个报文交给应用层而不用等代缓冲去装满
RST- 为 1 表示出现严重错误.可能需要重新创建 TCP 连接. 还可以用于拒绝非法的报文文段和拒绝连接请求
SYN - 为 1 表示这个连接请求或者是连接接受请求
FIN - 为 1 表示发送方没有要传送的数据了, 要求释放连接.
窗口 16 位 - 表示从确认号开始, 本报文的发送方可以接受的字节数,即接受窗口大小,用于流量控制.
校验和 16 位 - 对整个 TCP 报文段, 包括 TCP 头部和 TCP 数据, 以 16 位字进行计算所得.这是一个强制性字段
紧急指针 16 位 - 本报文段中的紧急数据的最后一个字节的序号
选项 最多 40 字节
0: 选项表结束 1 字节
1: 无操作用于选项字段之间的字边界对齐
2: 最大报文段长度 4 字节, (Maximum Segment Size, MSS)通常在创建连接而设置 SYN 标志的数据报中指明这个选项, 表示本端所能接受的最大长度的报文段. 通常将 MSS 设置为(MTU- 40) 字节, 携带 TCP 豹纹短的 iP 数据报的长度就不会超过 MTU( MTU 的最大长度为 1518 字节, 最短为 64 字节), 从而避免本季发生 IP 分片. 只能出现在同步报文段中, 否则会被忽略.
3: 窗口扩大因子 3 字节, 取值 0-14, 用来把 TCP 窗口的值左移的位数, 使窗口值乘倍. 只能出现在同步报文段中, 否则将被忽略. 这是因为现在的 TCP 接受数据缓冲区的长度通常大于 65535 字节.
4: sackOK 发送端支持并统一使用 SACK 选项
5: SACK 实际工作的选项.
8: 时间戳 10 字节
发送端时间戳 4 字节
时间戳应答 4 字节
HTTP(Hyper Text Transfer Protocol)协议
HTTP 是互联网上应用最为广泛的一种网络应用层协议. 所有的 WWW 文件都必须遵守这个标准.
HTTP 通常使用 TCP/IP 协议, 但在 HTTP 协议中并没有规定它必须使用会支持的下层协议. 事实上 HTTP 可以在任何互联网协议或其他网络上实现, HTTP 假定其下层协议提供可靠的传输. 因此任何能够提供这种保证的协议都可以被使用.
目前广泛使用的协议版本是 HTTP/1.1
HTTP 请求方法
GET: 向指定资源发出 “ 显示 ” 请求. 使用 GET 方法应该只用在读取资料, 而不应该被用于产生副作用的操作中. GET 的请求参数附带在 queryString 中.
HEAD:和 GET 请求一样, 都是向服务器发出指定资源的请求. 只不过服务器将不传回资源的内容, 仅发送资源的元信息(header).
POST: 向指定资源提交数据, 请求服务器处理.数据包含在请求体中, 这个请求可能后创建新的资源或修改现有资源, 或二者皆有.
数据格式主要又两种: application/x-www-form-urlencoded 和 multipart/form-data, 前者类似于 queryString, 后者主要用于文件等二进制数据传送.
PUT: 向指定资源上传最新内容( 全部数据, 包含未修改部分 )
PATCH: 向指定资源上传最新的变更( 仅包含修改部分 )
DELETE:请求删除指定资源
OPTIONS: 这个方法可使服务器传回该资源所支持的所有 HTTP 请求方法. 用 “*” 代替资源名称, 向 Web 服务器发送 OPTIONS 请求, 以测试服务器是否正常运作. 当发生跨域请求时, 浏览器会以 OPTIONS 请求来预检.
TRACE:回显服务器收到的请求, 主要用于测试.
CONNECT: HTTP/1.1 协议中预留给能够将连接改为隧道方式代理的服务器. 通常用于 SSL 加密的连接( 经由非加密的 HTTP 代理服务器 )
方法名称是区分大小写的. 当某个请求所针对的资源不支持对应的请求方法时, 服务器应当发回 405( Method Not Allowed ), 当服务器不认识挥着不支持对应的请求方法时, 应当回应 501( Not Implemented ).
安全方法
对于 GET 和 HEAD 方法而言, 除了获取资源信息外,这些请求不应该再具有其他意义. 也就是说, 这些方法应该被认为是安全的. 客户端可能会使用其他 非安全 的方法, 如 POST, PUT 和 DELETE, 应该以特殊的方式告知客户可能的后果.
副作用
假如在不考虑诸如错误或者过期等问题的情况下, 若干次请求的副作用与单词请求相同或者没有副作用, 那么这些请求方法被视作 幂等(idempotence)的. GET、HEAD、PUT 和 DELETE 方法都具有这样的幂等性, 同样根据协议, OPTIONS、TRACE 都不具有副作用, 因此也是幂等的.
如果一个由若干个请求组成的请求序列产生的结构, 在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化, 这这个请求序列是幂等的. 但是, 可能出现一个由若干请求组成的请求序列是 非幂等 的, 即日这个请求序列中所有的执行方法都是幂等的.
状态码
所有 HTTP 响应的第一行都是状态行, 依次是 HTTP 版本号、3 位数字组成的状态码, 以及买哦属性短语, 彼此由空格分割.
1xx - 请求已被服务器接受, 正在处理中
2xx - 请求已成功被服务器接受、理解并接受
3xx - 需要后续操作才能完成这一请求
4xx - 请求包含词法错误或者无法被执行
5xx - 服务器在主力某个正确请求时发生错误
虽然 RFC 2616 中已经推荐了描述状态的短语, 当开发者仍然能够执行决定采用何种短语, 用以显示本地化的描述信息.
常见 header
请求头
Accept: 能够接受的响应内容类型( COntent-Type ); Accept: text/plain
Accept-Charset: 能接受的字符集; Accept-Charset: utf-8
Accept-Encoding: 能接受的编码; Accept-Encoding: gzip, deflate;
Authorization: 用于超文本传输协议的认证信息; Authorization: Basic QWxhZGRXXXXXXXXXXXX==;
Cache-Control: 缓存控制; Cache-Control: no-cache;
Connection: 连接类型; Conenction: keep-alive;
Cookie: 之前由服务器通过 Set-cookie 下发的 Cookie; Cookie: var=1;var2=2;
Content-Length: 请求体长度; Content-Length: 345;
Content-Type: 请求体的数据类型; Content-Type: application/json;
Host: 服务器域名; Host: roadup.cc:1080
If-Match: 仅当客户端提供的实体与服务器上对应的实体相匹配时才进行相应的操作.( 用作 PUT 请求时, 仅当从用户三次更新某个资源以来, 该资源未被修改的情况下才更新该资源 ); If-Match: MD5(XXXX);
If-Modified-Since: 允许在对应的内容未被修改的情况下返回 304, 浏览器以缓存响应该请求; If-Modified-Since: Sat, 29 Oct 2017 20:30:00 GMT;
If-None-Match: 允许在对应的内容未被修改的情况下返回 304, 浏览器以缓存响应该请求; If-None-Match: MD5(XXXX);
If-Range: 如果该实体未被修改过, 则向我发送我缺少的那一个或多个部分, 否则发送整个新实体. If-Range: MD5(XXXX);
If-Unmodified-Since: 仅当该实体自某个特定事件以来未被修改的情况下, 才发送响应; If-Unmodified-Since: Sat, 29 Oct 2017 20:30:00 GMT;
Max-Forwards: 限制该消息可被代理及网关转发的次数; Max-Forwards: 10;
Origin: 发起一个跨域请求( 要求服务器在响应中添加一个允许来源的访问控制 Access-Control-Allow-Origin). Origin: https://roadup.cc
Range: 仅请求资源的一个范围, 字节偏移以 0 开始; Range: bytes=100-1000;
Referer: 表示浏览器所访问的前一个页面. Referer: https://roadup.cc/home/page.html?name=roadup
User-Agent: 浏览器的身份标识; User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.193 Safari/537.36
Upgrade: 要求服务器升级到另一个协议; Upgrade: HTTP/2.0;
响应头
Access-Control-Allow-Origin: 指定哪些网站可参与到跨域资源共享中; Access-Control-Allow-Origin: *;
Accept-Patch: 指定服务器支持的文件格式类型. Accept-Patch: text/plain;charset=utf-8;
Accept-Ranges: 这个服务器支持哪些种类的范围请求; Accept-Ranges: bytes;
Age: 这个资源在代理缓存种类存在的时间(秒); Age: 3600;
Allow: 对特定资源的有效动作; Allow: GET,HEAD;
Cache-Control: 向从服务器到客户端在内的所有缓存机制告知是否应该如何缓存这个资源. Cache-Control: no-cache, max-age=3600;
Connection: 针对该连接所预期的选项; Connection: close;
Content-Disposition: 可以让客户端下载文件并建议文件名, 文件名需要加 双引号; Content-Disposition: attachment; filename="file.doc"
Content-Encoding: 数据使用的编码类型; Content-Encoding: gzip;
Content-Length: 响应体的长度, 字节为单位; Content-Length: 200;
Content-Range: 这部分数据属于哪个资源的一部分;Content-Range: bytes 100-200/4000;
Content-Type: 当前内容的 MIME 类型; Content-Type: text/plain; charset=utf-8;
ETag: 对某个资源的某一版本的标识符, 通常是散列值, 用于协商缓存; ETag: MD5(xxxxxxxxx);
Expires: 资源的过期时间(绝对时间); Expires: Sat, 29 Oct 2017 20:30:00 GMT;
Last-Modified: 资源的最后修改时间;Last-modified: Sat, 29 Oct 2017 20:30:00 GMT;
Location: 重定向地址; Location: https://roadup.cc/home/page.html;
Set-Cookie: 在客户端设置 Cookie, 下次请求时会包含在请求头中; Set-Cookie: var1=val1;var2=val2;Max-Age=3600;httponly;
Upgrade: 要求客户端升级到另一个协议; Upgrade: HTTP/2;
红色部分字段用于缓存控制;
HTTP 缓存
通过复用以前获取的资源, 可以显著提高网站和程序的性能.
HTTP 缓存分为强缓存和协商缓存.
强缓存在缓存有效的情况下( 没有超过 Cache-Control 设定的的 max-age, 没有超过 Expires 设定的时间 )不会向服务器发出请求, 而是直接以缓存响应该请求. 命中强缓存时, http 请求的状态码时 200.
如果在强缓存生效期间, 资源被修改, 那么浏览器是拿不到最新资源的.
Pragma 和 Cache-Control 共存时的优先级 Pragma 的优先级高, 但 Pragma 并不是规范的缓存配置.
Cache-Control 在响应头中可能有几种值: no-store(不做任何缓存)、no-cache( 不做强缓存 )、max-age( 强缓存时长, 以秒为单位 )、public/private( 是否只能被单个用户使用, 中间代理是否缓存 )、must-revalidate( 厄秘次访问都需要校验 ).
在 Chrome 中命中强缓存会有两种情况
from memory cache: 一般缓存更新频率较高的资源
from disk cache: 缓存更新频率较低的资源
协商缓存是指在不确定缓存是否依然有效的情况, 浏览器会向资源发送请求, 并携带上次成功请求该资源的一些缓存信息, 有服务器决定是使用缓存还是使用服务端数据, 如果继续使用缓存这响应 304.
启用协商缓存需要服务端响应 ETag(文件 hash 值)/Last-Modified(最后修改时间, 精确到秒), 其中 ETag 的优先级更高, 在发起请求是会通过 If-None-Match 携带 ETag 信息, 以 If-Modified-Since 携带 Last-modified 信息.
随着前端工程化的逐渐兴起, 现在通常的做法是给资源( 非入口资源 index.html , 通常这个文件比较小)一个较长时间的强缓存(比如一年时间), 但有新版本发布时每个资源的文件名上都会附带其自身的 hash 值, 这样在下次请求的时候将不会命中缓存.
同源并发限制
为了防止过渡使用 http 请求, 浏览器对同一域名下的 TCP 连接有数量限制, 不同浏览器的限制并不都相同, 通常是 6 个. 浏览器通过线程池来管理 HTTP 请求线程, 这样可以将系统管理资源更多的用在实际用途, 而不是频繁的创建或销毁线程.
HTTPS ( SSL/TLS )
HTTPS 还是通过 HTTP 来传送信息, 但是信息是经过 TLS 协议加密的.
TLS 层位于传输层之上, 应用层之下. 首次 TLS 下一传输需要两个 RTT., 接下来可以通过 Session Resumption 减少到一个 RTT.
TLS 使用了两种加密技术
对称加密
对称加密就是两边拥有相同的密钥, 两边都知道如何加密解密.
非对称加密
有公钥和私钥之分, 公钥所有人都知道, 可以将数据用公钥加密, 但加密的数据必须使用私钥才能解密, 私钥只有分发公钥的一方才知道.
当我们使用 curl 查看请求过程时, 可以看到 TSL 的握手过程
客户端发起请求( ClientHello ), 并写到一下信息
支持的协议版本
客户端生成的随机数
支持的加密方法
支持的压缩方法
服务器回应( ServerHello )
确认使用的机密通信版本, 如果两端版本不一致名, 将会关闭加密通信
一个服务器生成的随机数
确认使用的机密方法
服务器证书
客户端回应
一个随机数, 该随机数用服务端公钥加密, 防窃听
编码改变通知, 表示随后信息都将使用双方商定的加密方法和密钥发送
客户端握手结束通知, 同时也是前面发送的所有内容的 hash 值, 用来服务器校验
服务端回应
编码改变通知, 表示随后的信息都将使用双方商定的加密方法和密钥发送
服务端握手结束, 这一项也是前面发送内容的 hash 值, 用来客户端验证.
[参考链接]
HTTP/2
HTTP 请求的第二个版本, 非加密连接 或基于 TLS/1.2 或以上的加密连接
HTTP/2 对 HTTP/1.1 有高度兼容, HTTP/2 采用了新的编码方式来传输数据
二进制分帧
有别于 HTTP/1.1 在连接中的明文请求, HTTP/2 将一个 TCP 连接分为若干个流, 每个流中可以传输若干个消息, 每个消息有若干个最小二进制帧组成.
多路复用
可以在一个 TCP 连接中, 发送多个请求, 避免重复的建立和销毁连接.
头部压缩
HPACK 算法是新引入 HTTP/2 的一个算法, 用于对 HTTP 的头部进行压缩. 在第一个请求发送时会携带全部的 header, 在后续的请求中, 只会携带一个指向缓存的 key, 对方会通过这个 key 找到完整的 header.
服务端推送
网站为了是请求数变少, 通常采用对页面上的图片、脚本进行极简化处理.
附: 体验 HTTP/2, 对比 HTTP/1.1
HTTP/3 ( QUIC )
目前 HTTP/3 协议的制定还处在工作中, 并未正式发布
HTTP/3 将弃用 TCP 协议, 改用基于 UDP 协议的 QUIC 协议实现.
QUIC( Quick UDP Internet Connections )是一种试验性的网络传输协议. 旨在提供几乎等同于 TCP 连接的可靠性, 但延迟大大减少.
QUIC 相比广泛使用的 http/2+tcp+tls 协议有一下优势
减少 TCP 三次握手及 TLS 握手时间
改进的拥塞控制
避免队头阻塞的多路复用
连接迁移
前向冗余纠错
WebSocket
websocket 是一种与 HTTP 不同的协议. 两者都位于 OSI 模型的应用层, 并且都依赖于传输层的 TCP 协议.
WebSocket 握手使用 HTTP Upgrade 头字段来从 HTTP 协议升级成 WebSocket 协议
与 HTTP 不同,WebSocket 提供全双工通信, 此外 WebSocket 还可以在 TCP 之上实现消息流.
优势
较少的控制开销, 在连接创建后, 服务器和客户端之间交换数据时, 用于协议控制的数据包头部相对较小. 在不包含扩展的情况下, 对服务器到客户端的内容,头部带下只有 2~10 字节.
更强的实时性.
保持连接状态
支持扩展
更好的压缩效果
字段
Connection 必须设置为 Upgrade, 表示客户端希望升级协议
Upgrade 字段必须设为 Websocket, 表示希望升级到 Websocket 协议
Sec-Websocket-Key 是随机字符串, 服务器会用这些数据构造一个 SHA-1 的信息摘要. 把 Sec-Websocket-Key 加上一个特殊字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11” 然后计算 SHA-1 摘要, 之后进行 Base64 编码, 将结果作为 Sec-Websocket-Accept 头字段的值, 返回给客户端.
Sec-Websocket-Accept: base64( sha1( requestHeader["Sec-Websocket-Key"] + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" ) )
Sec-Websocket-Version 表示支持的版本
https://www.yuque.com/roadup/frontend/ropvuh
版权声明: 本文为 InfoQ 作者【roadup】的原创文章。
原文链接:【http://xie.infoq.cn/article/ab3de31f3042af67bdbd8edc6】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
君子知命不惧，日日自新 2020.05.20 加入
还未添加个人简介
评论