关于jenkins的使用问题总结
公司jenkins目前的用途是与git stash集成，在提交代码之前强制跑单元测试，以保障代码质量。再使用的3个月了，也出现了很多问题，现总结总结：
ut运行环境：nodejs+node modules+mongodb++redis
1、必须保障code运行环境及依赖关系、权限、硬盘空间等，不然的话跑挂就是家常便饭；
2、testing环境code更新速度远大于mysql表结构修改速度，所有要及时修改jenkins上的表结构，不然也会挂一大片；
3、为什么每台jenkins server只能同时跑一个build，因ut环境的所有项目基本都依赖一套db，且跑ut之前会清空数据，故只能同时跑一个，这与公司项目的特定环境有关；
4、既然每台只能跑一个，那么多项目，每次commit都需要跑ut，跑一次短则几分钟，长则二三十分钟，那是远远不能满足需求，需要搭建jenkins的master-slave集群来消化build task 队列，master只做任务调度，slave执行时间build任务，各套环境要保证一直，最好通过虚机模板批量clone slave；
5、如果执行的命令有很多那，那么按顺序执行，其中一条出错后这个任务就会终止，返回值为非0，且每次的终止位置可能不一致，这与命令接受到termina信号有关；
6、出现ut跑不过的时候的排错方法：
关于jenkins故障排除的步骤和小技巧：
a、看一下jenkins上其他的build任务最近几个小时是否正常--&都失败的话--&问问同事mysql表结构是否有改变--&可以尝试重启jenkins--&还不行，找admin；
b、看一下jenkins上其他的build任务最近几个小时是否正常--&个别失败的话--&重新trigger2次--&看一下jenkins报错原因--&在本地用同样的build命令跑对应分支--&看本地报错和jenkins报错是否一致，报错一致说明代码有问题；
c、超过30分钟的build任务可以手工结束；
d、jenkins环境一般不会改变，除非npm install安装包，还有其他问题直接喊出来吧；
e、重启jenkins。
7、jenkins每次build都是去git checkout -f commit-num，可以在本地拿对应commit跑跑ut来troubleshooting；
8、多trigger几次吧
9、所有ut跑完后，通知stash的过程有时候可能会很长时间，jenkins的notify stash的这个插件没有timeout设置，时间太长就kill掉重新trigger吧。
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467142',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'使用email-ext替换Jenkins(Hudson)的默认邮件通知
使用email-ext替换Jenkins(Hudson)的默认邮件通知
发布时间： 3:39:17
编辑：www.fx114.net
本篇文章主要介绍了"使用email-ext替换Jenkins(Hudson)的默认邮件通知"，主要涉及到使用email-ext替换Jenkins(Hudson)的默认邮件通知方面的内容，对于使用email-ext替换Jenkins(Hudson)的默认邮件通知感兴趣的同学可以参考一下。
//hudson-email-ext/
1. 安装插件
& & Git Plugin (wiki.jenkins-ci.org/display/JENKINS/Git+Plugin)
& & GitHub Plugin (wiki.jenkins-ci.org/display/JENKINS/Github+Plugin)
& & Jenkins cross-platform shell plugin (wiki.jenkins-ci.org/display/JENKINS/XShell+Plugin)
& & Robot Framework plugin (wiki.jenkins-ci.org/display/JENKINS/Robot+Framework+Plugin)
众所周知，Jenkins(Hudson)默认提供了一个邮件通知，能在构建失败、构建不稳定等状态后发送邮件。但是它本身有很多局限性，比如它的邮件通知无法提供详细的邮件内容、无法定义发送邮件的格式、无法定义灵活的邮件接收配置等等。在这样的情况下，我们找到了Jenkins
Email Extension Plugin。该插件能允许你自定义邮件通知的方方面面，比如在发送邮件时你可以自定义发送给谁，发送具体什么内容等等。本文不会告诉你如何安装该插件，关于插件的安装请参考这里。
该插件扩展了Hudson构建默认的邮件通知功能，并赋予你更多更灵活的控制。它能在如下三块区域来自定义：
Triggers&-指定发送一封邮件通知应有的前置条件。Content&-&指定每封触发邮件的标题和正文的内容。Recipients&-.指定一封邮件触发后发送给谁来接收(邮件)。
它主要包含两个部分：基本配置和项目配置。
当然，在一个项目中应用email-ext插件之前，您必须做一些公共的配置。现在先跳转到Hudson的“系统配置”页面，如下图：
找到标题为“Extended E-mail Notification”的片段，你就能配置一些公共的email-ext属性。这些属性必须匹配你SMTP邮件服务器的设置。这一节不仅能配置成Hudson原有邮件通知的镜像(虽然有很多配置是一样的，但这是个不同的扩展点)，而且还增加了一些额外的功能。输入框中名为 Default Subject 和 Default Content 的项允许你在公共级别配置邮件的内容。这样做的话，可以使您为所有的项目按您的需求做更好的、更简单的配置。如下图。
根据帮助文档，我们可以了解到一些公共属性，下面我解释一下常用的属性。
属性详解：
Override Global Settings
如果不选，该插件将使用默认的E-mail Notification通知选项。反之，您可以通过指定不同于( 默认选项)的设置来进行覆盖。Default Content Type
指定构建后发送邮件内容的类型，有Text和HTML两种.Use List-ID Email Header
为所有的邮件设置一个List-ID的邮件信头，这样你就可以在邮件客户端使用过滤。它也能阻止邮件发件人大部分的自动回复(诸如离开办公室、休假等等)。你可以使用你习惯的任何名称或者ID号，但是他们必须符合如下其中一种格式(真实的ID必须要包含在&和&标记里)：
&pany.org&
Build Notifications &pany.org&
“Build Notifications” &pany.org&
关于更详细的List-ID说明请参阅RFC-2919.Default Subject
自定义邮件通知的默认主题名称。该插件能在邮件的主题字段中替换一些令牌，这样你就可以从构建中包含指定的输出信息。Default Content
自定义邮件通知的默认内容主体。该插件能在邮件的内容主体中替换一些令牌，这样你就可以从构建中包含指定的输出信息。Content Token Reference[公共配置]
所有的参数都是可选的，每个令牌的参数可以如下表示，字符串类型使用name=“value”，而布尔型和数字型使用name=value。如果{和}标记里面没有参数，则不会被解析。
示例：$TOKEN, ${TOKEN}, ${TOKEN, count=100}, ${ENV, var=”PATH”}
${BUILD_LOG,&maxLines,&escapeHtml} -显示最终构建日志。
maxLines&– 显示该日志最多显示的行数，默认250行。escapeHtml&-如果为true，格式化HTML。默认false。
${BUILD_LOG_REGEX,&regex,&linesBefore,&linesAfter,&maxMatches,showTruncatedLines,&substText,&escapeHtml,&matchedLineHtmlStyle}
-按正则表达式匹配显示构建日志的行数。
匹配符合该正则表达式的行数。参阅java.util.regex.Pattern，默认“(?i)\b(error|exception|fatal|fail(ed|ure)|un(defined|resolved))\b”。linesBefore&-包含在匹配行之前的行编号。行数会与当前的另一个行匹配或者linesAfter重叠，默认0。linesAfter&-包含在匹配行之后的行编号。行数会与当前的另一个行匹配或者linesBefore重叠，默认0。maxMatches&-匹配的最大数量，如果为0，则包含所有匹配。默认为0。showTruncatedLines&-如果为true，包含[...truncated ### lines...]行。默认为true。substText&-如果非空，把这部分文字插入该邮件，而不是整行。默认为空。escapeHtml&-如果为true，格式化HTML。默认false。matchedLineHtmlStyle&-如果非空，输出HTML。匹配的行数将变为&b style=”your-style-value”& html escaped matched line &/b&格式。默认为空。
${BUILD_NUMBER} -显示当前构建的编号。${BUILD_STATUS} -显示当前构建的状态(失败、成功等等)${BUILD_URL} -显示当前构建的URL地址。${CHANGES,&showPaths,&format,&pathFormat} -显示上一次构建之后的变化。
showPaths&– 如果为 true,显示提交修改后的地址。默认false。format&– 遍历提交信息，一个包含%X的字符串，其中%a表示作者，%d表示日期，%m表示消息，%p表示路径，%r表示版本。注意，并不是所有的版本系统都支持%d和%r。如果指定showPaths将被忽略。默认“[%a] %m\n”。pathFormat&-一个包含“%p”的字符串，用来标示怎么打印字符串。
${CHANGES_SINCE_LAST_SUCCESS,&reverse,&format,&showPaths,&changesFormat,pathFormat} -显示上一次成功构建之后的变化。
reverse&-在顶部标示新近的构建。默认false。format&-遍历构建信息，一个包含%X的字符串，其中%c为所有的改变，%n为构建编号。默认”Changes for Build #%n\n%c\n”。showPaths,&changesFormat,&pathFormat&– 分别定义如${CHANGES}的showPaths、format和pathFormat参数。
${CHANGES_SINCE_LAST_UNSTABLE,&reverse,&format,&showPaths,changesFormat,&pathFormat} -显示显示上一次不稳固或者成功的构建之后的变化。
reverse&-在顶部标示新近的构建。默认false。format&-遍历构建信息，一个包含%X的字符串，其中%c为所有的改变，%n为构建编号。默认”Changes for Build #%n\n%c\n”。showPaths,&changesFormat,&pathFormat&-分别定义如${CHANGES}的showPaths、format和pathFormat参数。
${ENV,&var} –&显示一个环境变量。
var&– 显示该环境变量的名称。如果为空，显示所有，默认为空。
${FAILED_TESTS} -如果有失败的测试，显示这些失败的单元测试信息。${JENKINS_URL} -显示Jenkins服务器的地址。(你能在“系统配置”页改变它)。${HUDSON_URL} -不推荐，请使用$JENKINS_URL${PROJECT_NAME} -显示项目的名称。${PROJECT_URL} -显示项目的URL。${SVN_REVISION} -显示SVN的版本号。${CAUSE} -显示谁、通过什么渠道触发这次构建。${JELLY_SCRIPT,&template} -从一个Jelly脚本模板中自定义消息内容。有两种模板可供配置：HTML和TEXT。你可以在$JENKINS_HOME/email-templates下自定义替换它。当使用自动义模板时，”template”参数的名称不包含“.jelly”。
template&-模板名称，默认”html”。
${FILE,&path} -包含一个指定文件的内容
path&-文件路径，注意，是工作区目录的相对路径。
${TEST_COUNTS,&var} -显示测试的数量。
var&– 默认“total”。
total -所有测试的数量。fail -失败测试的数量。skip -跳过测试的数量。
要想在一个项目中使用email-ext插件，你首先必须在项目配置页激活它。在”Post-build Actions”选项中勾选”Editable Email Notification”标签。
项目基本配置
当插件激活后你就能编辑如下三个字段：
Global Recipient List&-这是一个以逗号(或者空格)分隔的可接受邮件的邮箱地址列表。允许您为每封邮件指定单独的列表。Default Subject&-允许你配置令牌，这样就可以在项目中更容易地配置所有邮件的主题。Default Content&-跟 Default Subject的作用一样，但是是把主题替换内容主体。
项目高级配置
要查看插件的高级配置，请点击”Advanced”按钮。该选项允许您各种类型的邮件触发器指定接收者。默认情况下，唯一使用的触发器配置是”Failure”触发器。要增加更多的触发器，选择“Add a Trigger”旁边下拉列表中的类型，它会增加到控件上面的列表中。一旦你增加了一个触发器，你就可以对它做一些选择。如果你点击一个触发器旁边的”?”号，它将告诉你你在什么前置条件中来触发邮件发送。如下图。
Send to Recipient List&-如果勾选，邮件将发送到”Global Recipient List”中的所有邮件地址。Send to Committers&-该邮件会发给上次构建时检查过代码的人员，该插件会基于提交者的ID和追加Jenkins配置页面的(default email suffix)默认邮件后缀来生成一个邮件地址。譬如，上次提交代码的人是”first.last”， ，那么电子邮件将被发送到“first.last@
”。Send To Requester&-如果勾选，邮件将发送给构建触发者。Include Culprits&-如果勾选，而且 “Send To Committers”勾选，邮件将包含最后成功构建的提交者。More Configuration&-通过单击”+(expand)”链接您能为每个邮件触发器作更多单独的设置。
Recipient List&-这是一个以逗号(或者空格)分隔的可接受邮件的邮箱地址列表。如果触发就发送邮件到该列表。该列表会追加在”Global Recipient List”里。Subject&– 指定选择邮件的主题。注意：高级选项中的邮件触发器类型可覆盖对它的配置。Content&-指定选择邮件的内容主体。注意：高级选项中的邮件触发器类型可覆盖对它的配置。
Remove&-通过单击指定触发器当前行的”Delete”按钮，你可以删除该触发器。
项目邮件令牌
email-ext插件使用令牌来允许动态数据插入到邮件的主题和内容主体中。令牌是一个以$(美元符号)开始，并以空格结束的字符串。当一个邮件触发时，主题和内容主体字段的所有令牌都会通过真实的值动态地替换。同样，令牌中的“值”能包含其它的令牌，那将被替换成真实的内容。比如， $DEFAULT_SUBJECT令牌能通过从公共配置页面的Default Subject字段中的文本(或者其它令牌)替换。同理， $PROJECT_DEFAULT_SUBJECT令牌也能通过项目配置页面的Default
Subject 字段中值替换。
一旦你的项目中激活email-ext插件，它会使用默认值设置邮件的内容字段。项目配置页的默认主题和主体内容字段分别对应的是DEFAULT_SUBJECT和DEFAULT_CONTENT，因此它会自动地使用全局的配置。同理，每个触发器中的内容分别对应的是$PROJECT_DEFAULT_SUBJECT 和 $PROJECT_DEFAULT_CONTENT，所以它也会自动地使用项目的配置。由于令牌中的“值”能包含其它的令牌，这样一来，您就能为令牌快速地创建不同的切入点：全局级别(所有项目)，专属级别(单一项目)，通用级别(两者之间)。
如果你要查看所有可用的令牌，你可以点击项目配置页的Content Token Reference的?号获取详细的信息。
根据帮助文档，我们可以了解到一些公共属性，下面我解释一下常用的属性。
属性详解：
1、触发器类型
注意：所有的触发器都只能配置一次。
Failure：即时发送构建失败的邮件。如果”Still Failing”触发器已配置，而上一次构建的状态是”Failure”，那么”Still Failing”触发器将发送一封邮件来替代(它)。
Unstable：即时发送构建不稳固的邮件。如果”Still Unstable”触发器已配置，而上一次构建的状态是”Unstable”，那么”Still Unstable”触发器将发送一封邮件来替代(它)。
Still Failing：如果两次或两次以上连续构建的状态为”Failure”，发送该邮件。
Success：如果构建的状态为”Successful”发送邮件。如果”Fixed”已配置，而上次构建的状态为“Failure”或“Unstable”，那么”Fixed”触发器将发送一封邮件来替代(它)。
Fixed：当构建状态从“Failure”或“Unstable”变为”Successful”时发送邮件。
Still Unstable：如果两次或两次以上连续构建的状态为” Unstable “，发送该邮件。
Before Build：当构建开始时发送邮件。
2、Content Token Reference[项目配置]
注意：这里只解释系统配置页面中缺少的令牌。
${DEFAULT_SUBJECT} -这是Jenkins系统配置页面默认配置的邮件主题${DEFAULT_CONTENT} -这是Jenkins系统配置页面默认配置的邮件内容主体${PROJECT_DEFAULT_SUBJECT} –&这是项目的默认邮件主题。高级配置中使用该令牌的结果要优先于Default Subject字段。警告：不要在Default Subject 或者Default Content中使用该令牌，它会产生一个未知的结果。${PROJECT_DEFAULT_CONTENT} -这是项目的默认邮件内容主体。高级配置中使用该令牌的结果要优先于Default Content字段。警告：不要在Default Subject 或者Default Content中使用该令牌，它会产生一个未知的结果。
Jelly&脚本
从Jenkins(Hudson)2.9版本开始我们可以使用Jelly脚本。Jelly脚本跟Hudson的API挂钩，能获得你想要的任何信息，所以它很强大。插件有两个打包后的Jelly脚本，当然你也可以自定义(脚本)。
关于插件中默认的两个Jelly脚本：一个用来设计HTML格式邮件，另一个则是定义TEXT格式邮件。通过上面的截图看到它们的样子。你能通过使用模板参数指定插件调用哪一个脚本。它们的使用方法如下：
文本格式： ${JELLY_SCRIPT,template=”text”}HTML格式: &${JELLY_SCRIPT,template=”html”}
你也能编写属于自己的Jelly脚本。Jelly脚本能跟Hudson的API(包括hudson.model.AbstractBuild和hudson.model.AbstractProject)挂钩，因而特别强大。如果你打算这么做，你可以先参考现有的html和text脚本一探究竟。
值得注意的是，拥有Hudson管理员权限是使用自定义Jelly脚本(该脚本没有跟email-ext打包)的前提。脚本的生成步骤本身其实相对简单：
创建Jelly脚本。脚本的名称应该是&名称&.jelly。名称以.jelly结尾是很重要的。让你的Hudson管理员把脚本存放在HUDSON_HOME\email-templates文件夹里。使用Jelly令牌，让template匹配你的脚本名称(不要包含后缀)。比如，脚本的名称为foobar.jelly，则邮件内容中应该是${JELLY_SCRIPT,template=”foobar”}。
下面两个图就是就是使用Jelly脚本生成的邮件（最新版Email-ext新增html_gamil模板，它跟html模板类似，所以这里不再显示它的截图）：
以上就是我介绍的Email-ext插件，由于自己的局限，对于它的使用没有更深的了解。参考资料[2]中还有关于它的扩展，你也可以自行扩充它的功能。如果您有关于该插件以及Jenkins使用的更多更好的感受，我期待与您一起分享。
[1]&《Maven实战》第11章11.9邮件反馈。
[2]&https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
原创文章，转载请注明出处, 本文地址：&//hudson-email-ext/
Related Posts
Jenkins加Shell实现最简单的持续部署InfraDNA: Hudson之父的新公司Travis CI，翩翩而至的CI云别给我准备log配置InfoQ Maven专栏（四）——基于Maven的持续集成实践
本文标题：
本页链接：部署jenkins是遇到的问题汇总。
jenkins是非常方便的自动化构建攻击，在实际使用过程中还是遇到了很多的问题。
1、jsp-api 打包问题。
用mvn编译的时候需要依赖jsp-api，但是很多时候 jsp-api在tomcat等的lib下面存在，所以当打包成war文件的时候就重复了，这个时候经常会出问题
解决办法：在mvn的pom.xml里面设置
&dependency& &groupId&javax.servlet&/groupId& &artifactId&jsp-api&/artifactId& &version&2.0&/version& &scope&provided&/scope& &/dependency&
最后一个参数表示是参与编译，不打包。
2、在新版jenkins每次自动构建的时候，发现不是每次都更新svn仓库
解决办法：这个是设置问题，在Check-out Strategy，例如SVN， 选择EUse svn update as much as possible, with 'svn revert' before update，表示每次进行update后进行打包。
3、自动部署到tomcat
这个需要插件支持，默认安装后是不包括这个插件的，插件的名字是，在插件管理里面安装一下。
然后在job的构建后操作选择deploy war/ear to a container进行配置就可以了，唯一注意一点的是相对路径。
4、在自动部署到tomcat中，第一次是成功的，第二次就会把tomcat搞死，原因还不清楚，在tomcat中有日志，表示内存泄漏，日志如下：
严重: The web application [/mrc-web] registered the JDBC driver [net.sf.log4jdbc.DriverSpy] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
15:06:35 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads 严重: The web application [/mrc-web] appears to have started a thread named [MySQL Statement Cancellation Timer] but has failed to stop it. This is very likely to create a memory leak.
15:06:36 org.apache.catalina.startup.HostConfig checkResources 信息: Undeploying context [/mrc-web]
15:06:37 org.apache.catalina.startup.HostConfig deployWAR 信息: Deploying web application archive mrc-web.war
15:34:08 org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc 严重: The web application [/mrc-web] registered the JDBC driver [net.sf.log4jdbc.DriverSpy] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
15:34:09 org.apache.catalina.startup.HostConfig checkResources
如果有人能解决顺便说一下啊，非常感谢。
最后问题没有找到解决办法，换了另一种方式，但是前提是部署tomcat的机器和jenkins在一台机器上
就是在编译后执行一段windos脚本
net stop tomcat7 rmdir/s/q D:\apache-tomcat-7.0.22\webapps\mrc-web del mrc-web.war copy C:\progra~1\Jenkins\workspace\mrc\target\mrc-web.war &D:\apache-tomcat-7.0.22\webapps& net start tomcat7
就完成了部署。
4、&WARNING: clock of the subversion server appears to be out of sync. This can result in inconsistent check out behavior.&
这个在编译的时候有时候会有这个警告，主要是svn等服务器的时钟和本机的时钟有偏差，比如svn的时钟比较快，jenkins的时钟慢，当你提交svn的时候，紧接着进行jenkins构建，这个时候jenkins的svn update由于时钟原因就更新不到刚才的数据，但过了几分钟之后再进行更新的时候，超过两台机器的时间差，在次进行jenkins构建，就可以update到数据。
姐姐办法就很简单，两台机器的时间设置成一样就可以了。
5、mvn环境问题，这个不知道什么原因，部署好后会在c盘的跟目录下生成.m2文件夹， 里面也有仓库的目录。
这里面有个地方要注意，当有私有mvn仓库的时候，需要在里面配置settings.xml文件，不然会报错。
这个.m2和本机mavne的仓库不是一个，本机的一般放在系统用户下面的。
6、编译在windows下编译c++ &vs2008工程，其他类似
要下载msbuild插件，配置如下：
然后构件一个自由风格的软件项目的job
在添加构建步骤里面可以选择Build a Visual Studio project or solution using MSBuild
在MSBuild Build File中填写需要编译的工程可以是sln
在Command Line Arguments填写参数，当sln中有多个项目的时候可以选择需要构建的项目。&/t:Agent:Rebuild就可以了。
本分类共有文章16篇,更多信息详见
& 2012 - 2016 &
&All Rights Reserved. &
/*爱悠闲图+*/
var cpro_id = "u1888441";吴平福 的BLOG
用户名：吴平福
文章数：21
访问量：6757
注册日期：
阅读量：5863
阅读量：12276
阅读量：382050
阅读量：1073884
51CTO推荐博文
使用email-ext替换Jenkins(Hudson)的默认邮件通知
了这篇文章
类别：┆阅读(0)┆评论(0)今天看啥 热点：
jenkins 设置 smtp 发送邮件，jenkinssmtp
最关键的地方是，在系统管理员那个地方设置的email地址要和email配置的相同。见鬼，折腾了几个小时。
目测是你的邮件服务器 25端口被占用了，找管理员查一下 25端口被谁占用了
SMTP(Simple Mail Transfer Protocol)即简单邮件传输协议,它是一组用于由源地址到目的地址传送邮件的规则,由它来控制信件的中转方式。SMTP协议属于TCP／IP协议族,它帮助每台计算机在发送或中转信件时找到下一个目的地。通过SMTP协议所指定的服务器,我们就可以把E－mail寄到收信人的服务器上了,整个过程只要几分钟。SMTP服务器则是遵循SMTP协议的发送邮件服务器，用来发送或中转你发出的电子邮件。发送电子邮件的用户也必须为邮件客户程序设定一个SMTP服务器的地址，以指定您的信从哪一个服务器发出去。我们常见的ISP通常都设定一台计算机既是POP3服务器也是SMTP服务器。当然，如果对方不限定IP范围的话，您也完全可以选择其他ISP的SMTP服务器，这样做的代价往往是连接速度变慢。 发送邮件也可以通过Telnet的25号端口和SMTP服务器进行交互完成，首先应以本机地址做确认，并发送命令确认邮件地址和别名，然后发送邮件信息DNS 是域名系统 (Domain Name System) 的缩写，该系统用于命名组织到域层次结构中的计算机和网络服务。DNS 命名用于 Internet 等 TCP/IP 网络中，通过用户友好的名称查找计算机和服务。当用户在应用程序中输入 DNS 名称时，DNS 服务可以将此名称解析为与之相关的其他信息，如 IP 地址。因为，你在上网时输入的网址，是通过域名解析系解析找到相对应的IP地址，这样才能上网。其实，域名的最终指向是IP。 在IPV4中IP是由32位二进制数组成的，将这32位二进制数分成4组每组8个二进制数，将这8个二进制数转化成十进制数，就是我们看到的IP地址，其范围是在1～255之间。因为，8个二进制数转化为十进制数的最大范围就是1～255。现在已开始试运行、将来必将代替IPV6中，将以128位二进制数表示一个IP地址。 大家都知道，当我们在上网的时候，通常输入的是如：.cn 这样子的网址，其实这就是一个域名，而我们计算机网络上的计算机彼此之间只能用IP地址才能相互识别。再如，我们去一WEB服务器中请求一WEB页面，我们可以在浏览器中输入网址或者是相应的IP地址，例如我们要上新浪网，我们可以在IE的地址栏中输入：.cn 也可输入这样子 218.30.66.101 的IP地址，但是这样子的IP地址我们记不住或说是很难记住，所以有了域名的说法，这样的域名会让我们容易的记住。 DNS：Domain Name System 域名管理系统 域名是由圆点分开一串单词或缩写组成的，每一个域名都对应一个惟一的IP地址，这一命名的方法或这样管理域名的系统叫做域名管理系统。 DNS：Domain Name Server 域名服务器 域名虽然便于人们记忆，但网络中的计算机之间只能互相认识IP地址，它们之间的转换工作称为域名解析（如上面的......余下全文>>
相关搜索：
相关阅读：
相关频道：
&&&&&&&&&&&&
系统综合最近更新