文章目录
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/336f1eb18154948db936aba52b722102.png)
应用层简介: 应用层为每一类问题规定一种协议,其许多协议都是基于客户服务器的方式
应用层协议:
- HTTP(HyperText Transfer Protocol,超文本传输协议),用于实现 WWW(World Wide Web)服务
- DNS(Domain Name System,域名系统),用于实现域名到 IP 地址的映射
- FTP(File Transfer Protocol,文件传输协议),用于实现交互式文件传输功能
- SMTP(Simple Mail Transfer Protocol,简单邮件传送协议),用于实现电子邮箱传送功能
- SNMP(Simple Network Management Protocol,简单网络管理协议),用于管理与监视网络设备
- DHCP(动态主机配置协议)
- TELNET(远程终端协议)
- SMTP,POP3,IMAP 电子邮件
常用端口:
- TCP:HTTP 80,HTTPS 443,Telnet 23,FTP 20 21,SMTP 25
- UDP:DNS 53,SNMP 161 162,TFTP 69,RPC 111
1. HTTP 协议
HTTP 是用于从万维网(WWW)服务器传输超文本到本地浏览器的传送协议,是基于 TCP/IP 协议之上的应用层协议。HTTP 定义了客户端如何从服务器请求 Web 页面,以及服务器如何把 Web 页面传送给客户端。HTTP 采用了请求 / 响应模型,客户端向服务器发送一个请求报文,服务器以一个状态行作为响应。
【HTTP 特点】
- 简单快速:客户向服务器请求服务时,只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单,使得 HTTP 服务器的程序规模小,因而通信速度很快。
- 灵活:HTTP 允许传输任意类型的数据对象。 正在传输的类型由 Content-Type 加以标记。
- 无连接:无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求,并收到客户的应答后,即断开连接。采用这种方式可以节省传输时间。
- 无状态保存:HTTP 协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大(缺点)。另一方面,在服务器不需要先前信息时它的应答就较快,可以更快地处理大量事务(优点)。
- 支持 B/S 及 C/S 模式。
补充:对于无状态保存,如果用户登录一家购物网站,希望即使用户跳转到该站的其他页面也能继续保持登录状态。HTTP/1.1 虽然是无状态协议,但为了实现该保存状态的功能,引入了 Cookie 技术。
对于无连接,早期的 HTTP 是请求响应之后直接断开,但现在的 HTTP/1.1 不直接断开,而是等几秒钟,如果用户在这几秒钟之内有新的请求,那么还是通过之前的连接通道来收发消息,如果过了这几秒钟用户没有发送新的请求,那么就会断开连接,这样可以提高效率,减少短时间内建立连接的次数,因为建立连接也是耗时的。
【HTTP 各版本比较】
- HTTP 0.9:第一个 HTTP 版本,只支持 GET 请求。
- HTTP 1.0:支持 GET、HEAD、POST 方法;使用短连接(即为每个请求建立一个 TCP 连接,请求完成后立即断开连接),所以连接无法复用,每次连接都要经历三次握手和慢启动。
- HTTP 1.1:1)引入 keepalive 连接(长连接),以便连接复用。HTTP1.1 默认是长连接,而 HTTP1.0 使用长连接需要添加请求头 Connection: Keep-Alive。
- HTTP 2.0:1)多路复用:允许同时通过单一的 HTTP 连接发起多重的请求-响应消息;2)首部压缩;3)服务器端推流;
【HTTP 请求 + 响应步骤】
- 客户端连接到 Web 服务器:HTTP 客户端通常就是浏览器,与 Web 服务器的 HTTP 端口(默认为 80)建立一个 TCP 套接字连接,比如 http://www.abc.com
- 发送 HTTP 请求:通过 TCP 套接字,客户端向 Web 服务器发送一个文本的请求报文,一个请求报文由 请求行、请求头部、空行和请求数据 4 部分组成
- 服务器接受请求并返回 HTTP 响应:Web 服务器解析请求,定位请求资源并将资源复本写到 TCP 套接字,由客户端读取。一个响应由 状态行、响应头部、空行和响应数据 4 部分组成
- 释放 TCP 连接:若 connection 模式为 close,则服务器主动关闭 TCP 连接,客户端被动关闭连接,TCP 连接释放;若 connection 模式为 keepalive,则该连接会保持一段时间,在该时间内可以继续接收请求
- 客户端浏览器解析 HTML 内容:客户端浏览器首先解析状态行,查看表明请求是否成功的状态代码。然后解析每一个响应头,响应头告知以下为若干字节的 HTML 文档和文档的字符集。客户端浏览器读取响应数据 HTML,根据 HTML 的语法对其进行格式化,并在浏览器窗口中显示
1.1 HTTP 的请求与响应报文
【HTTP 请求(Request)】
客户端发送一个 HTTP 请求到服务器的请求消息包括:请求行(request line)、请求头部(header)、空行 和 请求数据 四个部分。
(1)HTTP 请求行: 包括请求方法、请求地址和协议版本
- 请求方法:HTTP/1.1 定义了 8 种请求方法,最常用的是 get 和 post
- 请求地址(URL):资源位置的识别方法,组成为
<协议>://<主机>:<端口>/<路径>?<参数>
,端口、路径和参数可以省略 - 协议版本:格式为
HTTP/主版本号.次版本号
,常用的有 HTTP/1.0 和 HTTP/1.1
(2)HTTP 请求头: 请求头信息为 名:值
对,之间用冒号分隔。请求头参数包括:
请求头 | 解释 | 示例 |
---|---|---|
Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
Accept-Charset | 通知服务端可以发送的编码格式,也即浏览器可以接受的字符编码集 | Accept-Charset: iso-8859-5 |
Accept-Encoding | 通知服务端可以发送的数据压缩格式,也即浏览器可以支持的压缩格式 | Accept-Encoding: compress, gzip |
Accept-Language | 通知服务端可以发送的语言,也即浏览器可接受的语言 | Accept-Language: en,zh |
Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
Authorization | 授权信息 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
Connection | 指定是否需要持久连接(HTTP 1.1默认进行持久连接) | Connection: close 或者 Connection: Keep-Alive |
Cookie | 最重要的请求头信息之一。HTTP请求发送时,会把保存在该请求域名下的所有cookie值一起发送给web服务器 | Cookie: $Version=1; Skin=new; |
Content-Length | 请求的内容长度 | Content-Length: 348 |
Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
Expect | 请求的特定的服务器行为 | Expect: 100-continue |
From | 发出请求的用户的Email | From: user@email.com |
Host | 指定接收请求的服务器地址,可以是“IP: 端口号”,也可以直接用域名 | Host: www.zcmhi.com |
If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功,未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
Referer | 先前网页的地址,当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
(3)空行: HTTP 请求头的最后会有一个空行,表示请求头部结束,接下来为请求数据,空行一定要有。
(4)请求数据: 请求数据不一定有,比如 get 请求就没有请求数据。
post 方法的请求报文举例:
# 请求行
POST /index.php HTTP/1.1
# 请求头
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length:25
Content-Type:application/x-www-form-urlencoded
--------------------空行--------------------
# 请求数据
username=aa&password=1234
【HTTP 响应(Response)】
服务器接收并处理客户端发过来的请求后会返回一个 HTTP 的响应消息,响应包括:状态行、响应头部、空行和 响应正文 四个部分。
(1)状态行: 包括协议版本、状态码和状态码描述。协议版本和请求报文一致,状态码是一个 3 位数字。
- 1xx:指示信息,表示请求已接收,继续处理
- 2xx:成功,表示请求已被成功接收、处理
- 3xx:重定向,要完成请求必须进行更进一步的操作
- 4xx:客户端错误,请求有语法错误或请求无法实现
- 5xx:服务器端错误,服务器未能实现合法请求
比较常见的状态码有:200 表示响应成功;302 表示跳转,跳转地址通过响应头中的 Location 属性指定;400 客户端请求有语法错误,不能被服务器识别;403 服务器接收到请求,但拒绝提供服务(认证失败);404 请求的资源不存在;500 服务器内部错误。
(2)响应头部: 与请求头部类似,为响应报文添加了一些附加信息。HTTP 响应头参数包括:
响应头 | 解释 | 示例 |
---|---|---|
Allow | 对某网络资源的有效的请求行为,不允许则返回405 | Allow: GET, HEAD |
Content-Encoding | web服务器支持的返回内容压缩编码类型 | Content-Encoding: gzip |
Content-Length | 响应体的长度 | Content-Length: 348 |
Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
Refresh | 应用于重定向或一个新的资源被创造,在5秒之后重定向(由网景提出,被大部分浏览器支持) | Refresh: 5; url=http://www.atool.org/httptest.php |
1.2 HTTP 请求方法
请求方法包含在请求行内:
- HTTP1.0 定义了三种请求方法: GET, POST 和 HEAD 方法。
- HTTP1.1 新增了五种请求方法:OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
GET:请求指定的页面信息,并返回实体主体。
POST:向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
HEAD:类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头。
PUT:从客户端向服务器传送的数据取代指定的文档的内容。
DELETE:请求服务器删除指定的页面。
CONNECT:HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
OPTIONS:允许客户端查看服务器的性能。
TRACE:回显服务器收到的请求,主要用于测试或诊断。
PUT和POST有什么不同:都是将一个资源附加到服务器端的请求,但 POST 方法用来传输实体的主体,PUT方法用来传输文件,自身不带验证机制。
1.2 HTTP 请求过程
建立 TCP 连接
Web 浏览器向 Web 服务器发送请求
Web 浏览器发送请求头信息
Web 服务器应答
Web 服务器发送应答头信息
Web 服务器向浏览器发送数据
Web 服务器关闭 TCP 连接
2. HTTPS 协议
HTTPS(Secure Hypertext Transfer Protocol)安全超文本传输协议,使用安全套接字层(SSL)进行信息交换,即 HTTPS 是使用了 TLS/SSL 加密的 HTTP 协议,基于非对称加密算法和对称加密算法的协作使用。
ps:TLS/SSL 指加密的规范,介于 TCP 和 HTTP 之间的安全协议,不影响原有的 TCP 和 HTTP 协议。
- SSL(Secure Socket Layer)安全套接字层,加密协议
- TLS(Transport Layer Security)安全传输层协议,是 SSL 的升级版本,更安全
2.1 TLS/SSL
TLS/SSL 协议就是客户端和服务器之间实现安全交换信息的协议。
TLS/SSL协议的三个特性:
- 加密传播:在握手协议中定义了会话密钥后,所有的消息都被加密,使得第三方无法窃听,解决 HTTP 通信的窃听风险;
- 身份证书:可选的客户端认证和强制的服务器端认证,防止身份被冒充,解决 HTTP 通信的冒充风险;
- 校验机制:传送的消息包括消息完整性检查,解决 HTTP 通信的篡改风险。
TLS/SSL 的功能实现主要依赖于三类基本算法:散列函数 Hash、非对称加密和对称加密。先利用非对称加密实现身份认证和密钥协商,再通过对称加密算法用协商好的密钥对数据加密,最后基于散列函数验证信息的完整性。
SSL 握手过程:
- ClientHello:客户端请求建立 SSL 连接,向服务器提供以下信息:1)支持的 SSL 协议版本,比如 TLS1.0;2)客户端生成的随机数,用于后续对称加密阶段生成对话密钥;3)支持的加密方法,比如RSA公钥加密。
- SeverHello:服务器对客户端的请求发出回应,包括以下信息:1)确认使用的 SSL 协议版本,如果服务器与客户端支持的版本不一致,服务器关闭通信;2)服务器生成的随机数,用于后续对称加密阶段生成对话密钥;3)确认使用的加密方法,比如 RSA 公钥加密;4)服务器证书。(如果服务器也需要确认客户端的身份,就会再包含一项信息,即要求客户端提供客户端证书,比如金融机构只允许认证客户连入自己的网络)
- 客户端收到服务器回应后,验证服务器证书的合法性,如果证书非可信机构颁布、证书已过期等,会提出警告,选择是否还要继续通信。如果证书没有问题,客户端就从证书中取出服务器的公钥。然后向服务器发送三个信息:1)用公钥加密的随机数(pre-master key);2)编码改变通知,表示随后的信息将用双方商量好的加密方法和密钥发送;3)客户端握手结束通知,这一项同时也是前面发送的所有内容的 hash 值,用于供服务器校验。
- 服务器的最后回应,服务器收到客户端的 pre-master key 之后,计算生成本次会话所用的会话密钥,然后向客户端发送以下信息:1)编码改变通知,表示随后的信息将用双方商量好的加密方法和密钥发送;2)服务器握手结束通知,这一项同时也是前面发送的所有内容的 hash 值,用于供客户端校验。
以上,握手阶段结束,客户端和服务器进入加密通信阶段,就是使用 HTTP 协议,只不过通信内容都用上面商定的会话密钥进行了加密。
Q:TLS/SSL 为什么要用 3 个随机数来生成对话密钥?
客户端和服务器都需要生成随机数,以保证每次生成的密钥都不同。
使用三个随机数,是因为 SSL 的协议默认不信任每个主机都能产生完全随机的数,如果只使用一个伪随机的数来生成秘钥,就很容易被破解。
通过使用三个随机数的方式,增加了自由度,一个伪随机可能被破解,但是三个伪随机就很接近于随机了,因此可以使用这种方法来保持生成秘钥的随机性和安全性。
2.2 非对称加密和对称加密
非对称加密:用于在 SSL 握手过程中加密生成的密码。一对多通信,分为公钥和私钥,公钥加密的信息只有私钥能解开(甚至公钥都不能解密出自己加密的信息),因此掌握公钥的不同客户端之间不能互相解密信息。常见非对称加密算法有 RSA、ECC、DH 等。
对称加密:用于加密真正要传输的数据。一对一通信,使用相同的密钥对信息进行加密和解密,只有掌握密钥才能获取信息,能够防止信息窃听。常见的对称加密算法有 AES-CBC、DES、3DES、AES-GCM 等。不同节点采用的对称密钥不同,从而保证了信息只能由通信双方获取。
Hash 算法:用于验证数据的完整性。哈希函数特性是单向不可逆,对输入非常敏感,输出长度固定,对原始数据的任何修改都会改变散列函数的结果,在这里用于防止信息篡改并验证数据的完整性。常见的算法有 MD5、SHA1、SHA256(Secure Hash Algorithm,安全哈希算法)。散列函数不能脱离加密进行信息防篡改,因为明文传输时中间人可以修改信息后重新计算信息摘要,因此需要对传输的信息及信息摘要进行加密。
为什么要配合使用非对称加密与对称加密,只用一个行不行?
只使用非对称加密:
- 拦截客户端报文,伪造公钥:当客户端初次向服务器请求公钥时,报文可能被黑客截获,黑客伪装服务器向客户端返回一个黑客生成的公钥,并且自己保留私钥。当客户端使用该黑客虚假公钥加密发送报文时,黑客就可以用私钥解密客户端发送的报文信息。
- 拦截服务端报文,伪造公钥:当客户端初次向服务器请求秘钥时,服务器返回公钥报文,中途被黑客截获,并且黑客修改报文中的公钥信息为黑客生成的公钥。当客户端发送使用黑客虚假公钥加密的报文给服务器时,可能被黑客截获报文信息并且用黑客私钥解密。
- 拦截服务端报文,解密返回给客户的报文信息:当客户端安全获得服务器发放公钥并且请求服务器时,服务器返回加密后报文信息。黑客可以截获服务器返回的报文信息,并且用公钥解密(因为公钥是大家都知道的),从而盗取服务器响应报文。
只使用对称加密:
- 拦截客户端报文,伪造秘钥:当客户端初次向服务器请求秘钥时,报文可能被黑客截获,黑客伪装服务器向客户端返回一个黑客生成的秘钥,当客户端使用该虚假秘钥发送报文时,黑客就可以解密客户端发送的报文信息。
- 拦截服务器报文,截获秘钥:当客户端初次向服务器请求秘钥是,服务器返回秘钥报文,中途被黑客截获,获得秘钥信息。当客户端发送加密报文给服务器或者服务器返回加密报文时都可能被截获报文信息并且解密。
2.3 HTTP 和 HTTPs 区别
HTTP 协议和 HTTPS 协议的区别:
1)HTTP 协议是以明文的方式在网络中传输数据,而 HTTPS 协议传输的数据则是经过 TLS 加密后的,HTTPS 具有更高的安全性。
2)HTTPS 在 TCP 三次握手阶段之后,还需要进行 SSL 的 handshake,协商加密使用的对称加密密钥。
3)HTTPS 协议需要服务端申请证书,浏览器端安装对应的根证书。
4)HTTP 协议端口是 80,HTTPS 协议端口是 443。
HTTPS 优点:
- HTTPS 传输数据过程中使用密钥进行加密,所以安全性更高
- HTTPS 协议可以认证用户和服务器,确保数据发送到正确的用户和服务器
HTTPS 缺点:
- HTTPS 握手阶段延时较高:由于在进行 HTTP 会话之前还需要进行 SSL 握手,因此 HTTPS 协议握手阶段延时增加
- HTTPS 部署成本高:一方面 HTTPS 协议需要使用证书来验证自身的安全性,所以需要购买 CA 证书;另一方面由于采用 HTTPS 协议需要进行加解密的计算,占用 CPU 资源较多,需要的服务器配置或数目高
3. DNS 域名系统
DNS(Domain Name System,域名系统),是用于实现域名和 IP 地址相互映射的一个分布式数据库,能够使用户更方便的访问互联网,而不用去记住能够被机器直接读取的 IP 数串。通过主机名,得到该主机名对应的 IP 地址的过程叫做域名解析(或主机名解析)。
如果整个因特网都使用一个域名服务器,负荷太大, 所以 DNS 设计成一个分布式的数据库,即使单个主机出故障也不会妨碍整个 DNS 系统。另外 DNS 使得大多数域名都能在本地解析,仅少量解析需要在因特网上通信,因此 DNS 效率很高。
3.1 DNS 解析过程
【域名结构 和 域名服务器】
域名结构:树状结构,树的最顶端代表根域名,下一层是 .com、.cn 等顶级域名,再下层就是二级、三级、四级域名。
域名服务器:
- 根域名服务器:最高层次的域名服务器,根域名服务器知道所有顶级域名服务器的域名和IP地址。任何一个本地域名服务器要对互联网上的任何域名进行解析,只要自己无法解析,就会首先求助于根域名服务器。
- 顶级域名服务器:管理在该顶级域名服务器下注册的所有二级域名。当收到DNS查询请求时,就给出相应的回答(可能是最后的结果,也可能是下一步需要去找的域名服务器的IP地址)。
- 权限域名服务器(权威域名服务器):负责一个区的域名服务器。当一个权威域名服务器不能给出最终的查询结果时,就会告诉发出请求方,下一步应该去找哪一个权威域名服务器。
- 本地域名服务器(递归服务器):主机发出 DNS 查询请求时,该请求首先会发给本地域名服务器。
理论上讲,任何标准域名的解析都需要经过层级式的域名解析。即首先要通过第一层的根域名服务器的指引,才能去下面的顶级域名服务器寻找。但是实际应用,提供接入服务的服务商的缓存域名服务器上可能已经有了域名与 IP 映射的缓存。
【DNS 解析流程】
- 在浏览器中输入 www.qq.com 域名,浏览器先检查自身缓存中有没有被解析过的这个域名对应的 IP 地址,如果有,就调用这个 IP 映射,完成域名解析。
- 如果浏览器缓存中未命中,操作系统会检查本地的 hosts 文件是否有该域名和 IP 的映射,如果有,就调用这个IP地址映射,完成域名解析。
- 如果 hosts 里也没有这个域名的映射,则向本地域名服务器(LDNS)发送请求,看是否有这个域名的映射关系,如果有,直接返回,完成域名解析。(LDNS 一般在城市的某个角落,距离你不会很远,一般都会缓存域名解析结果,大约 80% 的域名解析到这里就完成了)
- 如果 LDNS 仍然未命中,LDNS 就向根服务器发送查询请求,根服务器里面记录的都是各个顶级域所在的服务器 IP,根服务器会根据域名后缀返回对应的顶级域名服务器位置。当向根请求 www.qq.com 的时候,根服务器就会返回 .com 服务器的位置信息。
- LDNS 拿到 .com 的权威服务器地址以后,就会询问 .com 的权威服务器,知不知道 www.qq.com 的位置。这个时候 .com 权威服务器查找并返回 www.qq.com 服务器的地址。LDNS 继续向 www.qq.com 的权威服务器去查询这个地址,由 www.qq.com 的服务器给出了 IP 地址:202.173.11.10
- LDNS 服务器得到了 www.qq.com 对应的 IP 地址后以 DNS 应答包 的方式传递给客户机,并把域名和对应的 IP 地址在本地缓存下来。
- 客户机根据 IP 地址建立连接,并在客户端缓存域名/IP映射。
简单来说,其实只有四步:
- 在本地缓存里找映射,未命中继续下一步
- 在本地域名服务器(LDNS)里找映射,未命中继续下一步
- LDNS 向根域名服务器发送解析请求,期间迭代查询了顶级域名服务器和各权威域名服务器,LDNS 将解析结果 IP 返回给主机,并缓存域名-IP映射
- 主机在浏览器/OS缓存域名-IP映射,并建立连接
ps:本地域名服务器 = 递归域名服务器,意思是它的查询方式是递归的,即返回的是最终的查询结果而不是可能的查询路径。
【DNS 服务器查询方式:迭代查询和递归查询】
迭代查询:DNS 服务器会向客户机提供其他能够解析查询请求的 DNS 服务器地址,当客户机发送查询请求时,DNS 服务器并不直接回复查询结果,而是告诉客户机另一台 DNS 服务器地址,客户机再向这台 DNS 服务器提交请求,依次循环直到返回查询的结果为止。迭代查询返回的是最佳的查询点或者主机地址。本地域名服务器向根域名服务器的查询通常是采用迭代查询。
递归查询:DNS 服务器必须使用一个准确的查询结果回复客户机。如果DNS 服务器本地没有存储查询目标的 DNS 信息,那么该服务器会去询问其他服务器(即代替客户机去查询,而不是让客户机自己进行下一步查询),并将返回的查询结果提交给客户机。因此,递归查询返回的查询结果或者是所要查询的IP地址,或者是报错(表示无法查询到所需的 IP 地址)。主机向本地域名服务器的查询一般都是采用递归查询。
【DNS 查询响应类型】
DNS 服务器对客户机请求的答复包含以下类型:
- 权威答复:返回给客户机的正向答复,权威答复代表答复由具有权威的 DNS 服务器发送。
- 正向答复:正向答复包含了匹配客户端解析请求的资源记录。
- 参考答复:参考答复只在DNS服务器工作在迭代模式下使用,包含了其他有助于客户端解析请求的信息。例如,当DNS服务器不能为客户端发起的解析请求找到某个匹配值时,则向DNS客户端发送参考回复,告诉它有助于解析请求的信息。
- 否定答复:否定答复指出权威服务器在解析客户端的请求时可能遇到了以下两种情况之一:1)权威DNS服务器报告客户端查询的名字不存在,2)权威DNS服务器报告存在对应的名字但是不存在指定类型的资源记录。
【DNS 缓存机制】
DNS 缓存不仅产生于操作系统,浏览器、应用程序以及 ISP(网络服务提供商)都会对 DNS 进行缓存。
一条域名的 DNS 记录会在本地有两种缓存:浏览器缓存和操作系统缓存。在浏览器中访问的时候,会优先访问浏览器缓存,如果未命中再访问OS缓存,最后再访问 DNS 服务器(一般是ISP提供),然后 DNS 服务器会递归式的查找域名记录并返回结果。
DNS 记录会有一个 TTL 值(Time To Live,存活时间),单位是秒,代表这条记录最长有效期是多少。
- 浏览器 DNS 缓存的时间跟 DNS 服务器返回的 TTL 值无关。
- 应用程序的 DNS 缓存是由应用程序控制的,比如 Java 网络应用程序的 DNS 缓存是由 JVM 的缓存策略控制的。
- OS 缓存会参考 DNS 服务器响应的 TTL 值,但是不完全等于 TTL 值。
浏览器 DNS 缓存:浏览器在获取网站域名的实际 IP 地址后会对其 IP 进行缓存,减少网络请求的损耗。每种浏览器都有一个固定的 DNS 缓存时间,其中 Chrome 的过期时间是 1 分钟,在这个期限内不会重新请求 DNS。Chrome 浏览器看本身的 DNS 缓存时间比较方便,在地址栏输入:chrome://net-internals/#dns
,就能看到看浏览器的缓存。
Java DNS 缓存:Java 网络应用程序的 DNS 缓存是由 JVM 的缓存策略控制的,可以直接设置缓存过期时间:java.security.Security.setProperty("networkaddress.cache.ttl", 10);
ISP DNS 缓存:一般 ISP 服务器上缓存时间(15 min)比 OS 缓存时间长,就算刷新了本机操作系统的缓存,ISP 上仍然保留。
Windows DNS 缓存:Windows 访问 DNS 后会把记录保存一段短暂的时间,可通过 ipconfig /displaydns
查看 windows 的 DNS 缓存、通过 ipconfig /flushdns
来清除缓存。
IOS DNS 缓存:按照官方文档说法,IOS 设备上每 24 小时刷新一次 DNS 缓存。
3.2 DNS 欺骗
DNS 欺骗就是 攻击者冒充域名服务器的一种欺骗行为,攻击者用其窃取用户账号信息或者其他信息。
原理:攻击者冒充域名服务器,向主机提供错误的 DNS 信息。当用户尝试浏览网页,假如请求的是 www.qq.com,IP 为 xxx.xx.xx.xx,而实际上登录的是攻击者的主页,即 www.qq.com,IP 为 yyy.yy.yy.yy。
DNS 欺骗工作原理:首先欺骗者向目标机器发送构造好的ARP应答数据包,ARP欺骗成功后,嗅探到对方发出的DNS请求数据包,分析数据包取得ID和端口号后,向目标发送自己构造好的一个DNS返回包,对方收到DNS应答包后,发现ID和端口号全部正确,即把返回数据包中的域名和对应的IP地址保存进DNS缓存表中,而后来的当真实的DNS应答包返回时则被丢弃。
DNS 欺骗防范:
- 因为DNS欺骗前提也需要ARP欺骗成功。所以首先做好对ARP欺骗攻击的防范
- 不要依赖于DNS,尽管这样会很不方便,可以使用hosts文件来实现相同的功能
- 使用安全检测软件定期检查系统是否遭受攻击
操作系统级别的域名解析规程也被很多黑客利用,通过修改你的hosts文件里的内容把特定的域名解析到他指定的ip地址上,造成所谓的域名劫持。所以在windows7中将hosts文件设置成了readonly,防止被恶意篡改。
【问题】
(1)DNS 使用 UDP 还是 TCP?
DNS 占用 53 号端口,同时使用 TCP 和 UDP 协议。DNS 在进行区域传输的时候使用 TCP 协议,其它时候则使用 UDP 协议;
DNS 有两种类型的 DNS 服务器,主 DNS 服务器和辅助 DNS 服务器。在一个区中主 DNS 服务器从自己本机的数据文件中读取该区的 DNS 数据信息,而辅助 DNS 服务器则从区的主 DNS 服务器中读取该区的 DNS 数据信息。当一个辅助 DNS 服务器启动时,它需要与主 DNS 服务器通信,并加载数据信息,即区域传输(zone transfer)。
区域传送时使用TCP,因为:
- 辅 DNS 服务器会定时(一般时3小时)向主域名服务器进行查询以便了解数据是否有变动。如有变动,则会执行一次区域传送,进行数据同步。区域传送将使用 TC P而不是 UDP,因为数据同步传送的数据量比较大。
- TCP是一种可靠的连接,保证了数据的准确性。
域名解析时使用 UDP,因为:
客户端向 DNS 服务器查询域名,一般返回的内容都不超过 512 字节,用 UDP 传输即可。不用经过 TCP 三次握手,这样 DNS 服务器负载更低,响应更快。虽然从理论上说,客户端也可以指定向 DNS 服务器查询的时候使用 TCP,但事实上,很多 DNS 服务器进行配置的时候,仅支持 UDP 查询包。
(2)域名和 IP 是一对一关系吗?
实际上域名和 IP 是多对多关系。
- 一个 IP 可以被多个域名指向(购买的虚拟主机)
- 一个域名下也可以有多个 IP(负载均衡)
3. URI 和 URL
URI(Uniform Resource Identifiers):统一资源标识符
URL(UniformResourceLocator):统一资源定位符
URN(uniform resource name):统一资源命名
HTTP 使用 URI(统一资源标识符) 来传输数据和建立连接。URL(统一资源定位符) 是互联网上用来标识某一处资源的地址。URL 是一种特殊类型的 URI,包含了用于查找某个资源的信息。
3.1 URL 统一资源定位符
以 URL http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
为例,一个完整的 URL 包括以下几部分:
- 协议部分:该 URL 的协议部分为
http:
,表示网页使用的是 HTTP 协议,后面的//
为分隔符 - 域名部分:该 URL 的域名部分为
www.aspxfans.com
。URL 也可以直接用 IP 地址替换域名 - 端口部分:跟在域名后面的是端口,域名和端口之间使用
:
作为分隔符。端口不是一个 URL 必须的部分,如果省略端口部分,将采用默认端口 - 虚拟目录部分:从域名后的第一个
/
开始到最后一个/
为止,是虚拟目录部分。虚拟目录不是 URL 必须的部分。本例中的虚拟目录是/news/
- 文件名部分:从域名后的最后一个
/
开始到?
为止,是文件名部分;如果没有?
,则是从域名后的最后一个/
开始到#
为止;如果没有?
和#
,那么从域名后的最后一个/
开始到结束,都是文件名部分。本例中的文件名是index.asp
。文件名部分不是 URL 必须的部分,如果省略该部分,则使用默认的文件名 - 锚部分:从
#
开始到最后都是锚部分。本例中的锚部分是name
。锚部分不是 URL 必须的部分 - 参数部分:从
?
开始到#
为止之间的部分为参数部分,又称搜索部分、查询部分。本例中的参数部分为boardID=5&ID=24618&page=1
。参数可以允许有多个参数,参数与参数之间用&
作为分隔符
3.2 URI、URL 和 URN
URI(uniform resource identifier)统一资源标识符,用来唯一的标识一个资源。
- URL(uniform resource locator)统一资源定位器,它是一种具体的 URI,即 URL 不仅可以用来标识一个资源,而且还指明了如何 locate 这个资源。
- URN(uniform resource name)统一资源命名,通过名字来标识资源,但不指定如何定位资源。
URI 是以一种抽象的,高层次概念定义统一资源标识,而 URL 和 URN 则是具体的资源标识的方式。URL 和 URN 都是一种 URI。笼统地说,每个 URL 都是 URI,但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类,即 URN。
4. Session 和 Cookie
会话是指用户登录网站后的一系列动作,比如浏览商品添加到购物车并购买。会话跟踪是 Web 程序中常用的技术,用来跟踪用户的整个会话。常用的会话跟踪技术是 Session 和 Cookie。Cookie 通过在客户端记录信息确定用户身份,Session 通过在服务器端记录信息确定用户身份。
4.1 cookie
Cookie 是一小段文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用 response 向客户端浏览器颁发一个 Cookie,客户端会把 Cookie 保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该 Cookie 一同提交给服务器。服务器检查该 Cookie,以此来辨认用户状态。服务器还可以根据需要修改 Cookie 的内容。
由于HTTP是一种无状态的协议,服务器单从网络连接上无从知道客户身份。用户 A 购买了一件商品放入购物车内,当再次购买商品时服务器已经无法判断该购买行为是属于用户 A 的会话还是用户 B 的会话了。怎么办呢?就给客户端们颁发一个通行证吧,每人一个,无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。
登陆网站时,今天输入密码点击下次自动登录,下一次直接就登录了,此时用到的机制是 cookie。
【会话Cookie和持久Cookie】
- 会话 cookie:不设置过期时间,表示这个 cookie 的生命期为浏览器会话期间,关闭浏览器窗口 cookie 就会消失。会话cookie一般不存储在硬盘上而是保存在内存里。
- 持久 cookie:设置了过期时间,浏览器会把 cookie 保存到硬盘上,关闭后再次打开浏览器,这些 cookie 仍然有效,直到超过设定的过期时间。存储在硬盘上的 cookie 可以在浏览器的不同进程间共享。
Cookie 具有不可跨域名性,即浏览器访问百度不会带上谷歌的cookie。
4.2 session
Cookie 保存在客户端浏览器中,而 Session 保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录下来,客户端浏览器再次访问时只需要从该 Session 中查找该客户的状态就可以了。
购物网站的购物车添加一些物品,购物车的状态信息保存在 session。
1. 服务器怎么查找用户对应的 session? 每个用户与服务器建立连接的同时,服务器会自动为其分配一个Session id,以唯一地标识用户。
2. Seesion id 如何由用户传给服务器? 利用 cookie 传递
3.如果客户端浏览器禁用了 cookie,怎么传递 session id? 1)URL 重写,将 session id 直接附加再 URL 路径后面;2)表单隐藏字段,服务器修改表单添加一个隐藏字段,以便提交表单时可以将 session id 传回服务器。
4. 创建 seesion 的过程? 客户端创建请求,服务器首先检查这个客户端请求里是否包含了 session id,如果包含说明已经为此客户端创建过 seesion,直接利用 session id 检索对应的 seesion(如果检索不到会新建一个);如果不包含则为该客户端创建一个 session 并生成一个与此 session 相关的 session id,并在本次响应中返回给客户端保存。
参考资料:
HTTP 请求头各参数具体含义
https传输协议加密原理分析
DNS原理及解析过程详解
常见三种加密(MD5、非对称加密,对称加密)
HTTPS加密协议详解
SSL/TLS协议运行机制的概述
HTTPS的建立过程(SSL建立安全会话的过程)