Dns on ZRJ | 学习笔记

从点击到呈现 — 详解一次HTTP请求（2）

Sun, 30 Sep 2012 16:38:56 +0800

上回说道服务器启动了监听服务，准备迎接来自客户机的请求。那么，我们以一次典型的浏览请求来解析：

当我们开始在浏览器中输入网址的时候，浏览器其实就已经在智能的匹配可能得 url 了，他会从历史记录，书签等地方，找到已经输入的字符串可能对应的 url，然后给出智能提示，对于 google chrome 那种变态的浏览器，他甚至会直接从缓存中把网页展示出来，就是说，你还没有按下 enter，页面就出来了，这个过于奇葩，我们不详细讲。

在例如输入了 baidu 或者 qq 之类的域名后，我们可以按下 ctrl + enter ，来自动补全，生成 qq.com 或者 baidu.com 的网址，然后发起请求。请求一旦发起，浏览器首先要做的事情就是解析这个域名，一般来说，浏览器会首先查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址，说道这里，大家可能想到，这个地方就存在安全隐患了，如果有病毒把一些常用的域名，修改 hosts 文件，指向一些恶意的 ip，那么浏览器也会不加判断的去连接，是的，这正是很多病毒的惯用手法。

如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会向 dns 域名解析服务器发起域名解析请求，dns 的域名解析是递归的，（还有另外 dns 是迭代的），递归的 dns 首先会查看自己的 dns 缓存，如果缓存能够命中，那么就从缓存中把 ip 地址返回给浏览器，如果找不到对应的域名的 ip 地址，那么就向上转发请求，然后把得到的这个域名对应的 nameserver 的地址取得，再向这个 namserver 去请求域名对应的 ip，最后把这个 ip 地址返回给浏览器，不过怎么说，这个递归查询的过程，对于浏览器来说是透明的，他只要坐等 ip地址送回来就可以了。对于 DNS 的进一步理解，可以看这里，进一步理解 DNS

得到 ip 地址后，浏览器会开始构造一个 http 请求，一个典型的 http request header 一般需要包括请求的方法，例如 GET 或者 POST 等，不常用的还有 PUT 和 DELETE 方法，更加不常用的还有 HEAD 和 OPTION 以及 TRACE 方法，一般的浏览器只能发起 GET 或者 POST 请求，应用层的 http 请求准备好后，浏览器在传输层发起一条到达服务器的 tcp 连接，这个时候应该开始三次握手的过程，tcp 包被封装到网络层的 ip 包里面，ip 包再被封装到数据链路层的数据帧结构中，再通过物理层的比特流送出去，这些分层的意义在于分工合作，数据链路层通过 CSMA/CD 协议保证了相邻两台主机之间的数据报文传递，而网络层的 ip 数据包通过不同子网之间的路由器的路由算法和路由转发，保证了互联网上两台遥远主机之间的点对点的通讯，不过这种传输是不可靠，于是可靠性就由传输层的 tcp 协议来保证，tcp 通过慢开始，乘法减小等手段来进行流量控制和拥塞避免，同时提供了两台遥远主机上进程到进程的通信，最终保证了 http 的请求头能够被远方的服务器上正在监听的 http 服务器进程收到，终于，数据包在跳与跳之间被拆了又封装，在子网与子网之间被转发了又转发，最后进入了服务器的操作系统的缓冲区，服务器的操作系统由此给正在被阻塞住的 accept 函数一个返回，将他唤醒。

历史评论

smile (2013-09-09 16:57:20):

不是CSMA/CS协议，应该是CSMA/CD吧。

ZRJ (2013-09-09 18:37:07):

呵呵，是的，笔误，修改过来了，谢谢指出哈。。

Jacky (2014-05-02 11:20:15):

DNS部分，好像少了一个，浏览器自身的DNS缓存～

ZRJ (2014-05-03 09:38:38):

嗯，dns 这块确实没讲好，不够清晰易懂，不要被我误导了，哈哈，像 chrome 这种的，还有 chrome://dns/，里面还有 prefetch

老生常谈-从输入url到页面展示到底发生了什么丨 web技术笔记 (2017-09-01 14:38:22):

[…] http://zrj.me/archives/589 […]

从输入URL到页面显示发生了什么 | 言曌博客 (2018-03-07 14:07:34):

[…] http://zrj.me/archives/589 […]

xz (2019-01-28 15:35:08):

有线网络以太网采用的是CSMA/CD，but，无线网络Wi-Fi采用的是CSMA/CA，还是不太一样的。

ZRJ (2019-04-16 10:20:52):

嗯，是的，当时还没学习到无线，现在都是无线为主了，知识老旧了

进一步理解 DNS

Tue, 01 May 2012 22:54:13 +0800

把空间移到了新浪的 SAE 了，一来是发现海外的空间速度实在慢，在体会过新浪 SAE 的六线接入的一点瞬开的效果之后，直接被秒杀了，另外， DNS 的域名解析也迁移到了 DNSPod ，在 DNSPod 上做了 301 的跳转，于是现在的效果是速度很快，但是 URL 很恶心，不过权衡之后，我还是觉得速度更重要。

说说新浪的 SAE ，SAE 的应用商店里面有专门改写过的 WordPress ，主要是数据库层面改写了，具体的还没有研究，不过这是稍晚的事，我现在的想法是想先读读 WordPress 的源码，昨天安装的时候，发现 WordPress 可以发邮件通知，虽然这不是什么很高深的功能，但是我倒是想到当时我的主机上好像没有主动开启 SMTP 服务啊，那么 PHP 的 mail 函数是怎么发出邮件的呢？于是决定就这个好好研究一下 PHP 的邮件模块。另外一个发现的就是 WordPress 的搜索功能支持空格的，数据库上我当然是没有做全文检索的，那么这个功能又是怎么实现的呢，我目前就只能想到用 SQL 的 like 来拼接，具体的实现还是要读源码啊。

说说 DNSPod ，我们知道，一次 HTTP 请求发起之后，客户机会首先去用各种方法解析输入的域名，这里的各种方法包括本机的 hosts 文件，也包括请求网络的 DNS 服务，而 DNS 在各个层级都有缓存（相应的，缓存当然有过期时间，一般是 600 秒），在原来我的域名是托管在 Godaddy 做 A 解析的，域名的 NameServer 服务器当然是在海外，自然就慢了，后来迁移到新浪的 SAE 后，SAE 提供域名的绑定，但是要求做 CNAME 解析，可惜 Godaddy 是不支持对一级域名做 CNAME 解析的（估计是出于对 MX 解析冲突的考虑），于是没办法，我就把域名转到 DNSPod ，需要注意的是，这个地方的转移，其实只是把域名的解析服务转移出去，但是域名的根本管理权限还是在 Godaddy 的，怎么理解呢，简单的说，就是本来我们的机子向附近的 DNS 服务器请求解析域名，但是附近的 DNS 的并没有缓存我们请求的域名的记录，于是请求被向上转发，这里可能经过一次或者多次转发，然后到了某个层次的 DNS 服务器，一般是根服务器（顺便一提，DNS 的根服务器全球一共 13 台，没有一台在中国，具体情况可以参看维基百科的根域名服务器条目），他会最终处理这个请求，它查询发现我们这个被请求的域名是由类似 ns41.domaincontrol.com 或者 ns42.domaincontrol.com 这样的服务器解析的，但是，此处，根服务器并不会送佛送到西地找 ns41.domaincontrol.com 之类的解析，而是把这个负责域名的服务器地址返回给请求的服务器，于是下级的 DNS 向其中一个要求解析对应的地址，最终得到对应的 IP 地址，再层层下转，当然每层都应该会缓存，最后到了我们的机子，一次 DNS 解析请求就此完成，而在我们把域名转到 DNSPod 解析后，最终的解析请求就是由类似 f1g1ns1.dnspod.net 或者 f1g1ns2.dnspod.net 这样的服务器来解析的，这些服务器都是多线接入网络，自然响应速度比向海外的服务器请求要快了，到此，我们基本就理解了 A 解析了。

但是那个 301 是什么回事呢？其实，一般 301 服务器跳转的实现，都是由 DNS 的 NameServer 服务商自己开一个 HTTP 请求服务器来帮忙实现的，我们可以尝试着发送一个 HTTP 的 HEAD 类请求来验证：

Date: Tue, 01 May 2012 21:54:27 GMT
Server: DNSPod v1.0
Location: http://zrj0.sinaapp.com
Content-Length: 0
Connection: close

可以看到返回的 Server 是写着 DNSPod 的，通过一次 ping 请求我们可以进一步验证这个想法：

C:>ping zrj.me

正在 Ping dnspod-free.urlpod.cn [70.39.107.178] 具有 32 字节的数据:
来自 70.39.107.178 的回复: 字节=32 时间=211ms TTL=47
来自 70.39.107.178 的回复: 字节=32 时间=211ms TTL=47
来自 70.39.107.178 的回复: 字节=32 时间=211ms TTL=47
来自 70.39.107.178 的回复: 字节=32 时间=211ms TTL=47

70.39.107.178 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 211ms，最长 = 211ms，平均 = 211ms

C:>

可以清楚的看到，响应这个 ICMP 包的，就是 DNSPod 的服务器。至此，我们基本理解了 301 跳转类的域名解析服务了。

其他的比较少用，而且今天刚好发现 DNSPod 上的帮助写的很不错，简单易懂，直接引用过来：

A记录：地址记录，用来指定域名的IPv4地址（如：8.8.8.8），如果需要将域名指向一个IP地址，就需要添加A记录。 CNAME：如果需要将域名指向另一个域名，再由另一个域名提供ip地址，就需要添加CNAME记录。 TXT：在这里可以填写任何东西，长度限制255。绝大多数的TXT记录是用来做SPF记录（反垃圾邮件）。 NS：域名服务器记录，如果需要把子域名交给其他DNS服务商解析，就需要添加NS记录。 AAAA：用来指定主机名（或域名）对应的IPv6地址（例如：ff06:0:0:0:0:0:0:c3）记录。 MX：如果需要设置邮箱，让邮箱能收到邮件，就需要添加MX记录。 URL：从一个地址301重定向到另一个地址的时候，就需要添加URL记录（注：DNSPod目前只支持显性301重定向）。 SRV：记录了哪台计算机提供了哪个服务。格式为：服务的名字、点、协议的类型，例如：_xmpp-server._tcp。

各类型的记录值一般是这样的：

A记录：填写您服务器 IP，如果您不知道，请咨询您的空间商 CNAME记录：填写空间商给您提供的域名，例如：dnspod.cn MX记录：填写您邮件服务器的IP地址或企业邮局给您提供的域名，如果您不知道，请咨询您的邮件服务提供商 TXT记录：一般用于 Google、QQ等企业邮箱的反垃圾邮件设置 URL记录：填写要跳转到的网址，例如：http://www.baidu.com AAAA：不常用。解析到 IPv6 的地址。 NS记录：不常用。系统默认添加的两个NS记录请不要修改。NS向下授权，填写dns域名，例如：f1g1ns1.dnspod.net SRV记录：不常用。格式为：优先级、空格、权重、空格、端口、空格、主机名，记录生成后会自动在域名后面补一个“.”，这是正常现象。例如：5 0 5269 xmpp-server.l.google.com.

========== Update ==========

虽然 DNSPod 的域名解析是多线的，但是可惜的是，据官方说明，他的 301 服务器还是在海外，悲催的是，我转过来第一天就遇到 301 服务器悲剧的情况，于是现在 301 还是在 Godaddy 做。

历史评论

zz (2012-05-02 22:51:50):

请问你这个域名是怎么绑定的？有经过备案么？

ZRJ (2012-05-03 11:53:24):

域名是在 Godaddy 买的，不需要备案。绑定的话，在 Goaddy 的 DNS Manager 面板可以设置把域名指定到哪个 IP ，或者 CNAME 到哪个域名。

从点击到呈现 — 详解一次HTTP请求（2） | ZRJ (2012-10-05 08:28:45):

[…] 如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会向 dns 域名解析服务器发起域名解析请求，dns 的域名解析是递归的，（还有另外 dns 是迭代的），递归的 dns 首先会查看自己的 dns 缓存，如果缓存能够命中，那么就从缓存中把 ip 地址返回给浏览器，如果找不到对应的域名的 ip 地址，那么就向上转发请求，然后把得到的这个域名对应的 nameserver 的地址取得，再向这个 namserver 去请求域名对应的 ip，最后把这个 ip 地址返回给浏览器，不过怎么说，这个递归查询的过程，对于浏览器来说是透明的，他只要坐等 ip地址送回来就可以了。对于 DNS 的进一步理解，可以看这里，进一步理解 DNS […]