OSI七层模型
1. HTTP协议(重要)
建立TCP连接后,才能进行Http的请求、接收
请求报文
- 请求行 :包括用于请求的方法,请求URI和HTTP版本
- 请求头部 (Request headers)
- 请求数据 (Params)
响应报文
- 状态行 :包含表明响应结果的状态码(200、300…),原因短语和 HTTP 版本。
- 消息报头 (Response headers)
- 相应正文 (具体的html内容)
响应代码
2xx 响应成功
- 200 响应成功
3xx 客户端的跳转
- 301 标识客户端的跳转(永久性重定向)
- 302 客户端跳转(临时性重定向)
4xx 客户端错误
- 404 Not Found 页面不存在,服务器无法找到请求的资源
- 403 Forbidden 请求被服务器拒绝,客户端未获得访问权限
5xx 服务器错误
- 500 Internal Server Error 服务端错误,服务器端在执行请求时发生了错误
2. 通信协议(在传输层)
TCP/IP协议簇**:实际上是一种协议
- TCP:用户传输协议(打电话,电话通了才能聊)
- UDP:用户数据报协议(发短信、写邮件,发出去就不管了)
TCP/UDP两者对比
TCP:
- 连接,稳定
- 三次握手,四次挥手
最少三次,保证稳定连接
A:你愁啥?
B:瞅你咋滴?
A:干一场!
- 客户端、服务端
- 传输完成,释放连接,效率低
UDP:
- 不连接、不稳定
- 客户端、服务端没有明确的界限
- 不管有没有准备好,都可以发给你…
在TCP层,有个FLAGS字段,这个字段有以下几个标识
-
SYN 同步序列编号(Synchronize Sequence Numbers) :表示建立连接, 是 TCP/IP 建立连接时使用的握手信号
-
FIN (finish) 表示关闭连接
-
ACK (acknowledgement 确认)消息响应
-
PSH表示有 DATA数据传输
-
RST表示连接重置
3. 三次握手
示意
- 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
- 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
- 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端
目的
三次握手的目的是建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
4. 四次挥手
描述
断开一个 TCP 连接则需要“四次挥手”:
- 客户端-发送一个 FIN,用来关闭客户端到服务器的 数据传送
- 服务器-收到这个 FIN,它发回一 个 ACK,确认序号为收到的序号加1 。和 SYN 一样,一个 FIN 将占用一个序号
- 服务器-关闭与客户端的连接,发送一个FIN给客户端
- 客户端-发回 ACK 报文确认,并将确认序号设置为收到序号加1
为什么要四次
数据传输完毕后,双方都可释放连接。
关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。
5. 长连接
HTTP 协议的初始版本中,每进行一次 HTTP 通信就要断开一次 TCP 连接。
以当年的通信情况来说,因为都是些容量很小的文本传输,所以即使 这样也没有多大问题。可随着 HTTP 的普及,文档中包含大量图片的 情况多了起来。
比如,使用浏览器浏览一个包含多张图片的 HTML页面时,在发送 请求访问 HTML页面资源的同时,也会请求该 HTML页面里包含的 其他资源。因此,每次的请求都会造成无谓的 TCP 连接建立和断 开,增加通信量的开销。
为解决上述 TCP 连接的问题,HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久连接(HTTP Persistent Connections,也称为 HTTP keep-alive 或 HTTP connection reuse)的方法。持久连接的特点是,只要任意一端 没有明确提出断开连接,则保持 TCP 连接状态。
6. 代理、网关
代理
代理是一种有转发功能的应用程序,它扮演了位于服务器和客户 端“中间人”的角色,接收由客户端发送的请求并转发给服务器,同时 也接收服务器返回的响应并转发给客户端。
代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务 器。代理不改变请求 URI,会直接发送给前方持有资源的目标服务 器。
网关
网关是转发其他服务器通信数据的服务器,接收从客户端发送来的请 求时,它就像自己拥有资源的源服务器一样对请求进行处理。有时客 户端可能都不会察觉,自己的通信目标是一个网关。
如图,利用网关可以由 HTTP 请求转化为其他协议通信
网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提 供非 HTTP 协议服务。
利用网关能提高通信的安全性,因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。比如,网关可以连接数据库,使用SQL语句查询数据。另外,在 Web 购物网站上进行信用卡结算时, 网关可以和信用卡结算系统联动。
7. Https(Http+加密+认证+完整性保护 )
在 HTTP 协议中有可能存在信息窃听或身份伪装等安全问题。使用 HTTPS 通信机制可以有效地防止这些问题。
Http的缺点
-
通信使用明文(不加密),内容可能会被窃听
-
不验证通信方的身份,因此有可能遭遇伪装
-
无法证明报文的完整性,所以有可能已遭篡改
Https = Http+加密+认证+完整性保护
经常会在 Web 的登录页面和购物结算界面等使用 HTTPS 通信。使用 HTTPS 通信时,不再用 http://,而是改用 https://。另外,当浏览器访 问 HTTPS 通信有效的 Web 网站时,浏览器的地址栏内会出现一个带 锁的标记。对 HTTPS 的显示方式会因浏览器的不同而有所改变。
Https是身披SSL外壳的Http
HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)协议代 替而已。
通常,HTTP 直接和 TCP 通信。当使用 SSL时,则演变成先和 SSL通 信,再由 SSL和 TCP 通信了。简言之,所谓 HTTPS,其实就是身披 SSL协议这层外壳的 HTTP。在采用 SSL后,HTTP 就拥有了 HTTPS 的加密、证书和完整性保护 这些功能。
公开密钥加密
SSL采用一种 叫做公开密钥加密(Public-key cryptography)的加密处理方式。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥 (private key),另一把叫做公开密钥(public key)。顾名思 义,私有密钥不能让其他任何人知道,而公开密钥则可以随意发 布,任何人都可以获得。
使用公开密钥加密方式,发送密文的一方使用对方的公开密钥进 行加密处理,对方收到被加密的信息后,再使用自己的私有密钥 进行解密。利用这种方式,不需要发送用来解密的私有密钥,也 不必担心密钥被攻击者窃听而盗走。
github中git操作把公钥放到服务器中,私钥放在本地
CA证书
公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。
为了解决上述问题,可以使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书。
我们来介绍一下数字证书认证机构的业务流程。首先,服务器 的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证 机构在判明提出申请者的身份之后,会对已申请的公开密钥做数字签 名,然后分配这个已签名的公开密钥,并将该公开密钥放入公钥证书 后绑定在一起。
服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端,以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称 为证书。