HTTP协议

最新推荐文章于 2023-09-17 17:13:26 发布

zhuix7788

最新推荐文章于 2023-09-17 17:13:26 发布

阅读量249

点赞数

本文链接：https://blog.csdn.net/zhuix7788/article/details/86609351

版权

定义

是一种为分布式、协作式的，面向应用层的超媒体信息系统。它是一种通用的、无状态的协议。

全称Hyper Text Transfer Protocol，即超文本传输协议
是因特网上应用最为广泛的一种网络传输协议。所有的WWW文件必须遵守这个标准。
HTTP基于TCP/IP通信协议来传递数据(HTML 文件图片文件查询结果)
是一种按照URL指示，将超文本文档从一台主机(Web服务器)传输到另一台主机(浏览器)的应用层协议，以实现超链接的功能。
HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，此时即HTTPS

HTTP工作原理

HTTP协议工作于客户端-服务器架构上。浏览器作为HTTP客户端通过URL向HTTP服务端即WEB服务器发送所有请求。
Web服务器根据接收到的请求向客户端发送响应信息。
一个HTTP"客户端"是一个应用程序（Web浏览器或其他任何客户端），通过连接到服务器达到向服务器发送一个或多个HTTP的请求的目的。
一个HTTP"服务器"同样也是一个应用程序（通常是一个Web服务，如Apache Web服务器或IIS服务器等），通过接收客户端的请求并向客户端发送HTTP响应数据。
HTTP使用统一资源标识符（Uniform Resource Identifiers, URI）来传输数据和建立连接。
一旦建立连接后，数据消息就通过类似Internet邮件所使用的格式[RFC5322]和多用途Internet邮件扩展（MIME）[RFC2045]来传送

HTTP协议通信流程

在这里插入图片描述

HTTP需要注意事项

HTTP是无连接的：即限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即端口连接。(节省传输时间)
HTTP是媒体独立的：只要客户端和服务器知道如何处理的数据内容，任何类型的数据都可以通过HTTP发送。
HTTP是无状态的：指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样回导致每次连接传输的数据量增大。

所以我们要使用Cookies机制
用Session来保持状态

客户端请求消息

在这里插入图片描述

URL(统一资源定位符)

URL：Uniform Resource Locator：用于唯一地标识万维网中的某一个文档。
URL由协议、主机和端口(默认80)以及文件名三部分构成，基本格式为：

http://www.baidu.com:80/news/index.html
协议主机:端口80 文件名及其路径

URI：URI（Uniform Resource Identifiers）是统一资源标识符，用来唯一的标识一个资源。
Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是用一个URI来定位的。
URI一般由三部组成：
①访问资源的命名机制
②存放资源的主机名
③资源自身的名称，由路径表示，着重强调于资源。
URL和URI的区别：
URI强调的是给资源标记命名，URL强调的是给资源定位，但是你会发现，URL显然比URI包含信息更多，大多数情况下大家觉得给一个网络资源分别命名和给出地址太麻烦，干脆就用地址既当地址用，又当标记名用，所以，URL也充当了WWW万维网里面URI的角色，但是他比URI多了一层意义，我不光知道你叫什么，我还知道你在哪里。我们在浏览器输入的都是URL，因为我们输入的目的是为了找到某一个资源，当然你输入的是URI也是没错的，因为URL也是URI。

总结：URI标记了一个网络资源，仅此而已； URL标记了一个WWW互联网资源（用地址标记），并给出了他的访问地址。

请求方法

在这里插入图片描述

GET方法：请求参数和对应的值附加在URL后面，利用一个问号("?")代表URL的结尾与请求参数的开始，传递参数长度受限制。
例如：GET /search?hl=zh-CN&source=hp&q=domety&aq=f&oq=HTTP/1.1
参数为：

HI => zh-CN
Source => hp
q => domety
aq => f
oq => HTTP/1.1

POST方法：(弥补了GET不足)将请求参数封装在HTTP请求数据中，以名称/值的形式出现。
- 可以传输大量数据，对传送的数据大小没有限制
- 数据页不会显示在URL中
- 数据字符串保持在“请求内容”部分，各数据之间使用&隔开
对比：
- GET更灵活，POST更完善，短小无保密信息的数据使用GET发送，保密或者数据量大的使用POST来完成。
HEAD：像GET，只不过服务器接收到HEAD请求后只返回响应头，不会发送响应内容。
请求头部/请求报头
- Host：请求主机名
- User-Agent：产生请求的浏览器类型。例如：Mozilla/5.0 Firefox/19.0
- Accept：客户端可识别的内容类型列表
- Cookie：通过报文头属性传给服务器
Cookie: $Version=1;
Skin=new;jsessionid=5F4771183629C9834F8382E23BE13C4C

Response响应

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文
在这里插入图片描述

HTTP状态码

200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：

1** 信息，服务器收到请求，需要请求者继续执行操作
2** 成功，操作被成功接收并处理
3** 重定向，需要进一步的操作以完成请求
4** 客户端错误，请求包含语法错误或无法完成请求
5** 服务器错误，服务器在处理请求的过程中发生了错误
具体状态码信息可查看http://www.runoob.com/http/http-status-codes.html

首部字段或消息头

在这里插入图片描述

HTTP的扩展

Cache

缓存：使用缓存Cache的站点会监听客户端向服务器端发出的请求，并根据相应的缓存设置保持服务器端反馈的数据，比如HTML页面、图片等文件。如果用户再次使用相同URL发送请求，请求不会直接发向服务器，而是通过缓存策略先行判断是否能够使用之前已经保持下来的反馈文件，从而降低服务器的负载及提高数据的响应时间。

缓存策略的优点：

减少时延：因为发出网页请求是指向更接近客户端的缓存，而不再是源服务器端。
降低网络负荷：因为缓存文件可以重复使用，节省了带宽，降低网络负荷。

缓存类型

浏览器缓存：例如后退按钮直接返回网页
代理缓存
浏览器缓存由于客户端内存的限制不能存放过多的数据，否则会降低本机的性能。因此开发者需要存储大规模的数据及面向更广泛的用户群时，可以使用代理缓存，能够为几百甚至几千的使用者服务。
网关缓存
- 通常由网站站长部署，使网站更具可扩展性，可靠性
- 分类：强缓存、协商缓存

Cookie

Cookie的内容是保存的一小段文本信息，这些文本信息组成一份通行证。它是客户端对于无状态协议的一种解决方案。

Cookie的使用原理：

用户提供包括用户名在内的信息并提交给服务器
服务器向客户端回传相应数据的同时，发回Cookie S001
当客户端接收到来自服务器的响应后，浏览器会将Cookie S001存放在一个统一的位置。
客户端再向服务器发送请求的时候，会把Cookie S001再次发回至服务器

示例：登陆网站时提示“保存用户名”的选项，勾选后下次登陆时，页面自动填补用户名，这个功能是通过Cookie实现的。

Session

客户端访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上，这就是Session。客户端再次访问时只需要从该Session中查找该用户的状态即可。
它是客户端对于无状态协议的另一种解决方案。Cookie保存在客户端浏览器中，Session保存在服务器上。

Session的传输步骤

服务器端程序运行的过程中创建Session，并为该Session生成唯一的Session ID
服务器将Session ID发到客户端
客户端再次发送请求的时候，会将这个Session ID带上
服务器接收到请求之后会依据Session ID找到相应的Session，完成请求响应。

Session的弊端

服务器系统需要保存所有客户的Session ID，开销大
为了减小开销，如果使用集群，如何保证服务器之间的Session复制
对于过多的客户请求，反复查询数据库会造成性能问题。
为了更有利于CDN的运用，服务器是否可以只提供API？
解决方法：Token

Token

令牌(token)：签名后的用户身份信息
运用Token服务器就不再需要保存Session ID，只负责生成Token，然后验证Token。(用CPU计算时间换取Session存储空间)
原理

客户端第一次请求时，发送用户信息至服务器。服务器使用HS256算法及密匙进行签名，再将这个签名和数据一起作为Token，返回给客户端。
服务器端不保存Token，客户端保存Token
当客户端再次发送请求时，在请求信息中将Token一起发给服务器
服务器用同样的HSA256算法和同样的密匙再计算一次签名，和Token中的签名做比较。
- 如果相同，服务器就知道客户端已经登陆过了
- 如果不相同，数据部分肯定被篡改过，服务器就返回客户端：认证不通过。

HTTPS协议

HTTPS是以安全为目标的HTTP通道，即HTTP的安全版

协议由来

HTTP协议有一个致命的缺点：不够安全
HTTP协议的信息传输完全以明文方式，容易被中间人恶意截获并攻击。于是产生了对称加密。

对称加密
C/S之间通过约定一种对称加密方式，信息发送方使用密钥对信息加密，信息接收方通过同样的密钥对信息解密。
缺点：由于第一次约定加密方式和密钥的通信是明文，如果第一次通信就被拦截，密钥仍然会泄露给中间人。于是产生了非对称加密。
非对称加密

非对称加密的一组密钥对中，包含一个公钥和一个私钥。
公开密钥与私有密钥是一对，如果用公开密钥对数据进行加密，只有用对应的私有密钥才能解密；如果用私有密钥对数据进行加密，那么只有用对应的公开密钥才能解密。
双方都要产生一对公钥和私钥
具体流程：
C(客户端)先把自己的公钥Key1发给S；
S生成一个用于对称加密的密匙Key2，并用收到的Key1对Key2加密，发给C；
C利用私钥解开了Key1的加密，获得Key2的内容；
之后C和S之间利用Key2进行对称加密的通信。

这样，即使公钥Key1被截获，由于不知道私钥，也就无从解密。
缺点：中间人虽然不知道私钥，但截获Key1后自己生成一对公钥私钥Key3，并发给C，这样C和S的通信都要被中间人截获解密。

证书+数字签名方式
引入第三方：权威的证书颁发机构(CA)
证书包含内容

证书颁发机构	服务端网址
机构私钥加密(服务端公钥)	机构私钥加密(证书签名)

这里假设加密方式是MD5，将网站的信息加密后通过第三方机构的私钥再次进行加密，生成数字签名。

数字证书 = 网站信息 + 数字签名
在这里插入图片描述
MITM：Man-in-the-MiddleAttack
假如中间人拦截后把服务器的公钥替换为自己的公钥，因为数字签名的存在，会导致客户端验证签名不匹配，这样就防止了中间人替换公钥的问题

简要步骤：

服务端先把自己的公钥Key1发给证书颁发机构，向证书颁发机构申请证书
证书颁发机构也有一对公钥私钥。机构利用自己的私钥加密Key1，并通过服务端网址等信息生成一个证书签名，证书签名同样经过结构的私钥加密。
证书制作完成后，结构把证书发给服务端。
当C请求通信时，S直接将自己申请的证书返回给C
C收到证书后，首先验证证书的真伪。
(各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥)
所以C只需要知道是哪个机构颁布的证书，就可用从本地找到对应的机构公钥，解密出证书签名。
然后，C按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。
验证成功后，C就可以放心的再次利用机构公钥，解密出S的公钥Key1
C生成自己的对称加密密钥Key2，并且用服务器公钥Key1加密Key2，发给S
S用自己的私钥解开加密，得到对称加密密钥Key2。C和S开始用Key2进行对称加密的通信。

注：最新推出的TLS协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的。
浏览器安装后会内置一些权威第三方认证机构的公钥，比如VeriSign、Symantec以及GlobalSign等等，验证签名的时候直接就从本地拿到相应第三方机构的公钥，对私钥加密后的数字签名进行解密得到真正的签名，然后客户端利用签名生成规则进行签名生成，看两个签名是否匹配，如果匹配认证通过，不匹配则获取证书失败。

最后一个问题：浏览器和公证人之间的通信如何保证呢？
公证人的公钥可用在安装系统,或者安装浏览器的时候就进入用户的系统，用户先生成一组公私钥对，这样用户用公证人的公钥加密自己的公钥，发送给公证人，公证人用自己的私钥解密后获得客户的公钥。用客户的公钥加密服务器的公钥，发送给客户，客户用自己的私钥解密后获得服务器的公钥，这样客户用服务器的公钥加密信息，确保了只有真正的服务器才能获得解密内容。(有点绕，改天整理下)

加密算法

对称加密：典型的有DES、AES等
非对称加密：例如：RSA、DSA

数字签名

传输过程

客户端发起HTTPS请求
服务器端初步响应。服务器端将证书发回给客户端，证书包含证书的颁发机构、过期时间等。
客户端解析证书：验证证书的有效性，并生成一个随机值，用证书对该随机值进行加密。
客户端发送加密信息。（用证书加密后的公匙）
服务器解密信息。（对称加密）
服务器发送加密后的信息
客户端用之前生成的私钥解密服务器传过来的信息，客户端就获取了解密后的内容。

WebSocket协议

HTTP的三个缺点：

HTTP协议是符合请求响应模型基本特征的。
HTTP协议的服务器端不能主动给客户端发送请求
HTTP协议的无状态性

解决方案：

HTTP long poll
Ajax轮询
WebSocket协议

HTML5规范中，定义了WebSocket API。WebSocket API是下一代客户端-服务器的异步通信方法。取代了单个的TCP套接字，使用ws或wss协议。
- 优点：服务器和客户端可以在给定的时间范围内的任意时刻，相互推送信息。
- 协议关键内容：
Upgrade: websocket
Connection: Upgrade

Python发送HTTP协议

发送HTTP请求的协议
原生模块：http.client, urllib2
第三方模块：requests

	import requests
	test_url = "http://www.baidu.com"
	h = {"User-Agent":"Android/H60-L01/4.4.2/"}
	response = requests.get(test_url,headers=h)
	print (response.status_code)
	print (response.headers)
	print (response.text)

发送websocket请求
需安装模块：websocket、websocket-client

import websocket
url = "ws://www.XXXX.com/XXXX"
ws = websocket.create_connection(url)
ws.send("{"request":1111,"service":1001,"name":"xxxx"}")
new_msg = ws.recv()
print (new_msg)
ws.send("{"request":1111,"service":1003,"name":"x","message":"111111"}")
new_msg1 = ws.recv()
print (new_msg1)