网络分层模型
OSI七层模型
OSI 七层协议实现起来过分复杂,而且运行效率很低;制定标准的周期太长,当OSI 国际标准制定出来时,基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了。OSI 七层模型虽然失败了,但是却提供了很多不错的理论基础。为了更好地去了解网络分层,OSI 七层模型还是非常有必要学习的。
TCP/IP四层协议
HTTP超文本传输协议
域名解析过程
1.浏览器dns缓存;
2.系统dns缓存;
3.网络配置中的LocalDNS服务器(80%这一步就找到了);
4.根域名服务器(由LocalNDS请求并返回5的地址);
5.主域名/顶级域名服务器(全球只有几台/由LocalDNS请求并返回6的地址);
6.NameServer注册域名服务器(就是你注册域名的服务提供商)
HTTP 协是基于 TCP协议,发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面,默认是开启了 Keep-Alive ,这样的话建立的连接就可以在多次请求中被复用了。
HTTP/1.0 和HTTP/1.1
Cookie和Session
1. Cookie技术
Cookie是HTTP报文的一个请求头,Web应用可以将用户的标识信息或者其他一些信息(用户名等)存储在Cookie中。用户经过验证之后,每次HTTP请求报文中都包含Cookie,这样服务器读取这个Cookie请求头就知道用户是谁了。Cookie本质上就是一份存储在用户本地的文件,里面包含了每次请求中都需要传递的信息。
2. Session技术
由于Cookie以明文的方式存储在本地,而Cookie中往往带有用户信息,这样就造成了非常大的安全隐患。而Session的出现解决了这个问题,Session可以理解为服务器端开辟的存储空间,里面保存了用户的状态,用户信息以Session的形式存储在服务端。当用户请求到来时,服务端可以把用户的请求和用户的Session对应起来。那么Session是怎么和请求对应起来的呢?答案是通过Cookie,浏览器在Cookie中填充了一个Session ID之类的字段用来标识请求。
URI 和 URL 的区别是什么?
URI 的作用像身份证号一样,URL 的作用更像家庭住址一样。URL 是一种具体的 URI,它不仅唯一标识资源,而且还提供了定位该资源的信息。
状态码分类
HTTPS
HTTPS 是基于 HTTP 的,也是用 TCP 作为底层协议,并额外使用 SSL/TLS 协议用作加密和安全认证,解决了 HTTP 数据透明的问题。默认端口号是 443。
SSL 和 TLS 的区别 (没有太大区别)
SSL 指安全套接字协议(Secure Sockets Layer),首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本,SSL 1.0 从未面世,SSL 2.0 则具有较大的缺陷。
很快,在 1999 年,SSL 3.0 进一步升级,新版本被命名为 TLS 1.0。因此,TLS 是基于 SSL 之上的,但由于习惯叫法,通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。
SSL 和 TLS加密原理
HTTPS采用混合加密算法,即共享秘钥加密(对称加密)和公开秘钥加密(非对称加密)。TLS可以简单分为两步:1密钥交换;2数据加密。
非对称加密采用两个密钥(一个公钥,一个私钥)。在通信时,私钥仅由解密者保存,公钥由任何一个想与解密者通信的发送者所知。非对称加密设计了较为复杂的数学算法,在实际通信过程中,计算的代价较高,效率太低,因此,SSL/TLS 实际对消息的加密使用的是对称加密。
在双方通信之前,需要商量一个用于对称加密的密钥。我们知道网络通信的信道是不安全的,传输报文对任何人是可见的,密钥的交换肯定不能直接在网络信道中传输。因此,使用非对称加密,对对称加密的密钥进行加密,保护该密钥不在网络信道中被窃听。这样,通信双方只需要一次非对称加密,交换对称加密的密钥,在之后的信息通信中,使用绝对安全的密钥,对信息进行对称加密,即可保证传输消息的保密性。
为了公钥传输的信赖性问题,第三方机构应运而生——证书颁发机构(CA,Certificate Authority)。CA 默认是受信任的第三方。CA 会给各个服务器颁发证书,证书存储在服务器上,并附有 CA 的电子签名。当客户端(浏览器)向服务器发送 HTTPS 请求时,一定要先获取目标服务器的证书,并根据证书上的信息,检验证书的合法性。一旦客户端检测到证书非法,就会发生错误。客户端获取了服务器的证书后,由于证书的信任性是由第三方信赖机构认证的,而证书上又包含着服务器的公钥信息,客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
带有证书的公钥传输机制(SSLClient-SSLServer握手过程)
[事前两点准备工作]:
参考:SSL:握手过程详解 - 知乎
1. client--->server:Client hello
2. server--->client:Server hello
3. server--->client:Certificate
4. server--->client:Server Key Exchange
该帧只存在于秘钥交换算法(Key Exchange)为 DH 或 ECDH 的帧中。如果秘钥交换算法为 RSA,那么此帧不存在。
5. server--->client:Certificate Request
该帧存在于双向验证过程中,用于请求客户端证书。
6. server--->client:Server Hello Done
通知客户端 Server Hello 相关的信息已经发送完成。
7. client--->server:Client Key Exchange
RSA Key Exchange:
DH(ECDH)Key Exchange:
8. client--->server:Certificate Verify
该帧存在于双向验证过程中,用于客户端自证该证书属于客户端。
9. client--->server:Change Cipher Spec
客户端告知服务器,客户端已经生成了主秘钥,并且后续的通信将使用该秘钥进行加密。
10. client--->server:Encrypted Handshake Message
这是客户端使用主秘钥加密的第一个数据,发向服务器。服务器使用此消息验证自身生成的主秘钥的正确性。
11. server--->client:Change Cipher Spec
服务器告知客户端,服务器已经生成了主秘钥,并且后续的通信将使用该秘钥进行加密。
12. server--->client:Encrypted Handshake Message
这是服务器使用主秘钥加密的第一个数据,发向客户端。客户端使用此消息验证自身生成的主秘钥的正确性。
双向认证和单项认证
双向认证一般是在客户端验证服务端的基础上,加上服务端对客户端的验证,这要求
会话密钥重用
SSL/TLS握手过程比较繁琐,同时非对称加解密性能比对称密钥要差得多;如果每次重建连接时都需要进行一次握手会产生较大开销,因此有必要实现会话的重用以提高性能。
常用的方式包括:
SessionID(RFC 5246),客户端和服务端同时维护一个会话ID和会话数据状态;重建连接时双方根据sessionID找到之前的会话密钥实现重用;
SessionTicket(RFC 5077),由服务端根据会话状态生成一个加密的ticket,并将key也发给客户端保证两端都可以对其进行解密。该机制相较sessionID的方式更加轻量级,服务端不需要存储会话状态数据,可减轻一定压力。
其它应用层协议
Telnet:远程登陆协议
SSH:安全的网络传输协议
Telnet 协议 通过一个终端登陆到其他服务器,建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据(包括用户名和密码)均以明文形式发送,这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种非常安全的协议SSH所取代的主要原因。
FTP:文件传输协议
主要提供文件传输服务,基于 TCP 实现可靠的传输。使用 FTP 传输文件的好处是可以屏蔽操作系统和文件存储方式。