HTTP基础知识
HyperText Transfer Protocol 超文本传输协议,这个可能是我们对于HTTP知晓的最广泛的一个知识点。用于分布式,协作式与超媒体信息系统的应用层协议。HTTP是万维网的数据通讯基础,设计初期目的仅仅是为了提供一种发布和接收HTML页面的方法。
HTTP是一个客户端(用户)和服务器(网站)请求和应答的标准(TCP)。通过使用浏览器、爬虫或者其它的工具,客户端发起一个HTTP请求到服务器上指定端口(默认端口为80)。我们称这个客户端为用户代理程序(user agent)。应答的服务器上存储着一些资源,比如HTML文件和图像。我们称这个应答服务器为源服务器(origin server)。在用户代理和源服务器中间可能存在多个“中间层”,比如代理服务器、网关或者隧道(tunnel)。
HTTP 0.9:一行协议
最早期 HTTP 为1991年诞生被设计用于从服务器获取 HTML 文档,
1 | GET /xxx.html |
整个协议只有一行,GET
请求方法以及文档路径,极为简单。当时的 HTTP 只支持 GET
方法,路径是文档在服务器的位置,即实际要获取的内容。请求以换行结束。
HTTP 0.9的简单功能:
- 客户端/服务端、请求/响应协议
- ASCII协议,运行与TCP/IP链接之上
- 设计用于传输超文本文档(HTML)
- 客户端与服务端的连接在每次请求之后关闭
HTTP 1.0:迅速发展标准
在1996年,一个更加全面,完整的协议规范,1.0正式发布
1 | GET /xxx.html HTTP/1.0 |
1 | HTTP/1.0 200 OK |
相对0.9而言的关键变化:
- 请求可以由多行首部字段构成
- 响应对象前添加响应状态行
- 响应对象也有自己换行分隔的首部字段
- 响应对象不仅限于超文本
- 客户端与服务端的连接在每次请求之后关闭
HTTP 1.1:互联网标准
HTTP协议之所以能如此被广泛使用的主要原因为,在早期的HTTP标准中,只考虑协议的便捷性,而完全不考虑其性能问题,使得简单可用变成HTTP早期标准的准则。
HTTP 1.1标准理清之前版本中一些歧义内容,并且添加了许多的性能优化:
- 持久化连接以支持连接重用
- 分块编码以支持流式响应
- 请求管道以支持并行请求处理
- 字节服务以支持基于范围的资源内容请求
- 改进的更好的缓存机制
HTTP 2.0:改进传输性能
HTTP的简单本质是其最初得以采用以及后期快速发展的关键,但是互联网的高速发展,其弊端开始显现。
HTTP工作组于2012年宣布开发HTTP2.0,目标为改进传输性能,实现低延迟和高吞吐量。
扩展一下:
HTTP为客户端与服务端之间最常用的协议,通过请求与响应的交换达成协议。
请求包含:方法,URI,版本协议,请求首部以及请求内容实体。
响应包含:版本协议,状态码,状态短语,响应首部和主体
HTTP方法
- GET 获取资源 (HTTP1.0)
- POST 传输实体主体 (HTTP1.0)
- PUT 传输文件 (HTTP1.0)
- HEAD 获取报文头部 (HTTP1.0)
- DELETE 删除文件 (HTTP1.0)
- OPTIONS 查询支持的方法 (HTTP1.1)
- TRACE 追踪路径 (HTTP1.1)
- CONNECT 使用隧道连接代理 (HTTP1.1)
通用:
请求:
响应:
TCP/IP与HTTP的关系
IP:Internet Protocol 因特网协议 负责互联网主机之间的路由选择和寻址
TCP:Transmission Control Protocol 传输协议负者在不可靠的传输信道上提供可靠的抽象层
在Internet上,HTTP通讯通常发生在TCP/IP连接之上,缺省端口是TCP 80,但其它的端口也是可用的。
一次HTTP创建的过程:
名词
- SYN表示建立连接
- FIN表示关闭连接
- ACK表示响应
- PSH表示有DATA数据传输
- RST表示连接重置
三次握手
- SYN:客户端选着一个随机序列号x,发送一个SYN分组,其中可能包含其他的TCP标志和选项,而后进入SYN_SEND状态,等待服务器确认。
- SYN ACK:服务器接受到该SYN分组之后需要确认,便向x+1,并且使用另一个随机序列号y,追加自身的标志和选项,返回响应SYN ACK分组,此时服务器进入SYN_RECV状态
- ACK:客户端接收之后,对于x,y均加1,返回握手的随后一次ACK分组,客户端和服务器进入ESTABLISHED状态,完成三次握手。
四次挥手
- 客户端发送一个FIN分组,用来告知服务器关闭数据传输
- 服务器收到FIN分组后,响应一个ACK分组,告知客户端收到该关闭TCP的通知,但此时并未真正关闭TCP,可能仍有数据进行响应中
- 在数据全部传输完毕之后,服务器发送一个FIN分组给到客户端
- 客户端发回ACK分组确认,并将确认序号加1确认
慢启动
慢启动是一种TCP拥塞控制机制,当TCP建立完毕,开始传输数据时,为避免由于发送了过量的数据而导致阻塞会首先慢慢的对网路实际容量进行试探,不断的加大拥塞窗口来加大吞吐量。
TCP核心原理的影响
- 三次握手增加一整次的往返时间
- TCP慢启动被用到了每一次TCP链接
- 流量控制与拥塞控制影响所有链接的吞吐量
- 吞吐量由当前拥塞窗口大小控制
TCP性能检测清单
- 服务器内核升级最新版本
- 确保拥塞窗口大小为10
- 慢启动重启:在连接空闲时禁用慢启动
- 确保启动拥塞窗口缩放
- 减少传输冗余数据
- 压缩传输数据
- 减少资源与用户的物理距离
- 最大可能重用TCP连接
什么是HTTPS
Hypertext Transfer Protocol Secure 超文本传输安全协议,HTTP over TLS,简称HTTPS。
- 内容加密,建立一个信息安全通道保证数据传输的安全
- 身份认证确认网站的真实性
- 数据完整性防止内容被篡改
传输应用数据之前,客户端必须与服务端协商密钥、加密算法等信息,服务端还要把自己的证书发给客户端表明其身份,这些环节构成 TLS 握手过程
- TLS基于可靠的传输层TCP之上运行,意味着首先完成TCP的三次握手,一整次的往返
- TCP连接建立之后,客户端将自身支持的加密套件,运行的TLS协议版本等发送给服务器
- 服务器接受到数据之后,选择一组加密算法,并将自己的身份信息等以证书的形式返回相应,其中包含加密公钥,最为可选项,服务器也可以发送一个请求,要求客户端提供证书等信息
- 在两端确定了共同版本以及加密套件之后,客户端会生成一个对称秘钥,使用服务端的公钥进行加密发送给服务端,到此除了加密的对称秘钥,其余的均为明文形式发送
- 服务端在接受到数据之后,使用自身的私钥来解密获得对称秘钥,返回给客户端一个加密的响应
- 客户端利用对称秘钥解密,然后两方均使用对称秘钥进行加密通讯。
HTTP 2.0的进化之道
协议关注的问题与目标
- 创建协商协议标准,应用层协议协商(ALPN),以便客户端能够从HTTP/1.0、HTTP/1.1、HTTP/2或其他非HTTP协议中做出选择
- 与HTTP/1.1在请求方法、状态码乃至URI和绝大多数HTTP头部字段等方面保持高度兼容性。
- 减少网络延迟,提高浏览器的页面加载速度
- 支持现有HTTP应用场景,包括桌面和移动设备浏览器,网络API,不同规格的网络服务器和正向代理、反向代理服务器软件,防火墙,CDN等
同时请求 379 张图片来组成下面的大图片,其优势显而易见。
再看下请求
简单介绍
- 帧、消息和流
与HTTP/1.1在连接中的明文请求不同,HTTP/2,将一个TCP连接分为若干个流(Stream),每个流中可以传输若干消息(Message),每个消息由若干最小的二进制帧(Frame)组成。
流:已建立连接上的双向字节流
消息:与逻辑消息对应的完整的一系列数据帧
帧:HTTP 2.0通讯的最小单位,每个帧包含帧首部,标识所属的流
所有的HTTP 2.0通讯都在一个TCP连接上完成,可以承载任意数量的双向数据流,每个数据流以消息的形式发送,而每个消息由一个或者多个帧组成,帧可以乱序发送,再由帧首部进行重新组装。
- 多路复用&请求管道化
数据传输采用多路复用形式,多请求合并在同一TCP连接内
可以并行交错的发送请求,之间互不干扰。
可以并行交错的发送响应,之间互不干扰。
一个连接可并发多个请求与响应。
消除不必要的延迟。
HTTP首部字段压缩(HPACK算法)
服务端推送(Server Push)
服务器可以对客户端的一个请求发送多个响应,例如对于请求一个HTML页面,无需浏览器解析之后在请求响应资源,在初期请求HTML页面时,服务端可以及时推送页面所需的资源内容。
HTTP知识对于性能优化的意义
所有应用都应该致力于消除或者减少不必要的网络延时,将传输的数据压缩至最小,是web性能最基础优化实践。
- 减少DNS查找
- 重用TCP连接
- 减少HTTP重定向
- 使用CDN
- 去掉不必要的资源
- 在客户端缓存资源
- 压缩传输数据
- 消除不必要的请求开销
- 并行处理请求与响应
- 针对版本进行优化措施