-
java时间操作函数汇总
2011-07-28 17:10:04
-
java -D的参数
2011-07-28 10:04:38
-
转载：测试流程——眼熟
2011-07-24 22:41:28
-
loadrunner_http长连接设置
2011-07-22 17:54:50
最近协助同事解决了几个问题，也对loadrunner的一些设置加深了理解，关键是更加知其所以然。
1. loadrunner_internet运行时设置 总览:
2. 中文乱码_设置自动字符集转换
3.loadrunner_连接下载超时_tcp是否使用长连接设置
帮助文档中的说明：
随后在脚本中进行了不同的设置，进行了结果验证：3.1 默认值：设置 Keep-Alive HTTP connections ---> Yes
在此设置情况下访问baidu首页，请求头如下图：
3.2 随后，修改 设置 Keep-Alive HTTP connections ---> No
在此设置情况下访问baidu首页，请求头如下图：
3.3通过对比，可以发现：
此设置生效了，而且是通过设置HTTP请求头中的参数实现的，和下述的文章所说相符。4.至于tcp连接建立连接3次握手，关闭连接4次握手。有兴趣的可以验证下。
附TCP状态变化图：
下面列一些参考文章，感觉还是蛮有收获的。
HTTP长连接定义：
What is HTTP Persistent Connections?
HTTP persistent connections, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using the same TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new one for every single request/response pair. Using persistent connections is very important for improving HTTP performance.什么是HTTP长连接？
HTTP长连接，与一般每次发起http请求或响应都要建立一个tcp连接不同，http长连接利用同一个tcp连接处理多个http请求和响应，也叫HTTP keep-alive，或者http连接重用。使用http长连接可以提高http请求/响应的性能。
5.HTTP无状态协议和Connection:Keep-Alive容易犯的误区
http://liuzhigong.blog.163.com/blog/static/178272375201141344312315/名词解释：HTTP无状态：无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。从另一方面讲，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系当你登录到一个网站时，你的登录状态也是由Cookie或Session来“记忆”的，因为服务器并不知道你是否登录优点：服务器不用为每个客户端连接分配内存来记忆大量状态，也不用在客户端失去连接时去清理内存，以更高效地去处理WEB业务缺点：客户端的每次请求都需要携带相应参数，服务器需要处理这些参数Keep-Alive：参考另外一篇文章HTTP Keep-Alive 详解容易犯的误区：1、HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）2、从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接3、Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间6. http长连接与短连接
http://www.cnblogs.com/Roberts/archive/2010/12/05/1986550.html
可以了解下常见的通信场景：一、长连接与短连接：
长连接：client方与server方先建立连接，连接建立后不断开，然后再进行报文发送和接收。这种方式下由于通讯连接一直存在。此种方式常用于P2P通信。
短连接：Client方与server每进行一次报文收发交易时才进行通讯连接，交易完毕后立即断开连接。此方式常用于一点对多点通讯。C/S通信。二、长连接与短连接的操作过程：
短连接的操作步骤是：建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接长连接的操作步骤是：建立连接——数据传输...（保持连接）...数据传输——关闭连接三、长连接与短连接的使用时机：
长连接：短连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况。每个TCP连接的建立都需要三次握手，每个TCP连接的断开要四次握手。如果每次操作都要建立连接然后再操作的话处理速度会降低，所以每次操作下次操作时直接发送数据就可以了，不用再建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，频繁的socket创建也是对资源的浪费。短连接：web网站的http服务一般都用短连接。因为长连接对于服务器来说要耗费一定的资源。像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。试想如果都用长连接，而且同时用成千上万的用户，每个用户都占有一个连接的话，可想而知服务器的压力有多大。所以并发量大，但是每个用户又不需频繁操作的情况下需要短连接。总之：长连接和短连接的选择要视需求而定。四、发送接收方式：
1、异步：报文发送和接收是分开的，相互独立，互不影响的。这种方式又分两种情况：
异步双工：接收和发送在同一个程序中，有两个不同的子进程分别负责发送和接送。异步单工：接送和发送使用两个不同的程序来完成。2、同步：报文发送和接收是同步进行，即报文发送后等待接送返回报文。同步方式一般需要考虑超时问题，试想我们发送报文以后也不能无限等待啊，所以我们要设定一个等待时候。超过等待时间发送方不再等待读返回报文。直接通知超时返回。
五、报文格式：
通信报文格式多样性更多，相应地就必须设计对应的读写报文的接
收和发送报文函数。阻塞与非阻塞方式
1、非阻塞方式：读函数不停的进行读动作，如果没有报文接收到，等待一段时间后超时返回，这种情况一般需要指定超时时间。2、阻塞方式：如果没有接收到报文，则读函数一直处于等待状态，知道报文到达。循环读写方式
1、一次直接读写报文：在一次接收或发送报文动作中一次性不加分别地全部读取或全部发送报文字节。2、不指定长度循环读写：这一版发生在短连接进程中，受网络路由等限制，一次较长的报文可能在网络传输过程中被分解成很多个包，一次读取可能不能全部读完一次报文，这就需要循环读取报文，知道读完为止。3、带长度报文头循环读写：这种情况一般在长连接中，由于在长连接中没有条件能够判断循环读写什么时候结束。必须要加长度报文头。读函数先是读取报文头的长度，再根据这个长度去读报文，实际情况中，报头码制格式还经常不一样，如果是非ASCII的报文头，还必须转换成ASCII常见的报文头编制有：1、n个字节的ASCII码。2、n个字节的BCD码。3、n个字节的网络整型码。以上是几种比较典型的读写报文方式，可以与通信方式模板一起 预先提供一些典型的API读写函数。
当然在实际问题中，可能还必须编写与对方报文格式配套的读写API. 在实际情况中，往往需要
把我们自己的系统与别人的系统进行连接， 有了以上模板与API,可以说连接任何方式的通信程序
都不存在问题。
7. http长连接技术文章翻译——关于http长连接有很多重要的概念
http://www.blogjava.net/xjacker/articles/334709.html尝试翻译片技术文章。
What is HTTP Persistent Connections?
HTTP persistent connections, also called HTTP keep-alive, or HTTP connection reuse, is the idea of using the same TCP connection to send and receive multiple HTTP requests/responses, as opposed to opening a new one for every single request/response pair. Using persistent connections is very important for improving HTTP performance.
什么是HTTP长连接？
HTTP长连接，与一般每次发起http请求或响应都要建立一个tcp连接不同，http长连接利用同一个tcp连接处理多个http请求和响应，也叫HTTP keep-alive，或者http连接重用。使用http长连接可以提高http请求/响应的性能。There are several advantages of using persistent connections, including:
Network friendly. Less network traffic due to fewer setting up and tearing down of TCP connections.
Reduced latency on subsequent request. Due to avoidance of initial TCP handshake
Long lasting connections allowing TCP sufficient time to determine the congestion state of the network, thus to react appropriately.
使用http长连接有很多好处，包括：
更少的建立和关闭tcp连接，可以减少网络流量。
因为已建立的tcp握手，减少后续请求的延时。
长时间的连接让tcp有充足的时间判断网络的拥塞情况，方便做出下步操作。
The advantages are even more obvious with HTTPS or HTTP over SSL/TLS. There, persistent connections may reduce the number of costly SSL/TLS handshake to establish security associations, in addition to the initial TCP connection set up.
In HTTP/1.1, persistent connections are the default behavior. of any connection. That is, unless otherwise indicated, the client SHOULD assume that the server will maintain a persistent connection, even after error responses from the server. However, the protocol provides means for a client and a server to signal the closing of a TCP connection.
这些优点在使用https连接时更显著。可以减少多次建立高消耗的SSL/TLS握手。
在HTTP/1.1中，默认使用的是长连接方式。客户端默认服务端会保持长连接，即便返回错误响应；除非明确指示不使用长连接。同时，协议中也指定了客户端可以发送关闭信号到服务端来关闭TCP连接。
What makes a connection reusable?
Since TCP by its nature is a stream based protocol, in order to reuse an existing connection, the HTTP protocol has to have a way to indicate the end of the previous response and the beginning of the next one. Thus, it is required that all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection). Self demarcation is achieved by either setting the Content-Length header, or in the case of chunked transfer encoded entity body, each chunk starts with a size, and the response body ends with a special last chunk.
怎样是连接可以重用？
因为TCP是基于流的协议，所以HTTP协议需要有一种方式来指示前一个响应的结束和后一个响应的开始来重用已建立的连接。所以，它要求连接中传输的信息必须有自定义的消息长度。自定义消息长度可以通过设置 Content-Length 消息头，若传输编码的实体内容块，则每个数据块的标明数据块的大小，而且响应体也是以一个特殊的数据块结束。
What happens if there are proxy servers in between?
Since persistent connections applies to only one transport link, it is important that proxy servers correctly signal persistent/or-non-persistent connections separately with its clients and the origin servers (or to other proxy servers). From a HTTP client or server's perspective, as far as persistence connection is concerned, the presence or absence of proxy servers is transparent.
若中间存在代理服务器将会如何?
因为长连接仅占用一条传输链路，所以代理服务器能否正确得与客户端和服务器端（或者其他代理服务器）发送长连接或非长连接的信号尤为重要。但是HTTP的客户端或服务器端来看，代理服务器对他们来说是透明的，即便长连接是需要关注的。What does the current JDK do for Keep-Alive?
The JDK supports both HTTP/1.1 and HTTP/1.0 persistent connections.When the application finishes reading the response body or when the application calls close() on the InputStream returned by URLConnection.getInputStream(), the JDK's HTTP protocol handler will try to clean up the connection and if successful, put the connection into a connection cache for reuse by future HTTP requests.
The support for HTTP keep-Alive is done transparently. However, it can be controlled by system properties http.keepAlive, and http.maxConnections, as well as by HTTP/1.1 specified request and response headers.
当前的JDK如何处理Keep-Alive？
JDK同时支持HTTP/1.1 和 HTTP/1.0。
当应用程序读取完响应体内容后或者调用 close() 关闭了URLConnection.getInputStream()返回的流，JDK中的HTTP协议句柄将关闭连接，并将连接放到连接缓存中，以便后面的HTTP请求使用。
对HTTP keep-Alive 的支持是透明的。但是，你也可以通过系统属性http.keepAlive和http.maxConnections以及HTTP/1.1协议中的特定的请求响应头来控制。The system properties that control the behavior. of Keep-Alive are:
http.keepAlive=<boolean>
default: trueIndicates if keep alive (persistent) connections should be supported.
http.maxConnections=<int>
default: 5Indicates the maximum number of connections per destination to be kept alive at any given time
HTTP header that influences connection persistence is:
Connection: closeIf the "Connection" header is specified with the value "close" in either the request or the response header fields, it indicates that the connection should not be considered 'persistent' after the current request/response is complete.
控制Keep-Alive表现的系统属性有：
http.keepAlive=<布尔值>
默认: true
指定长连接是否支持
http.maxConnections=<整数>
默认: 5
指定对同一个服务器保持的长连接的最大个数。
影响长连接的HTTP header是：
Connection: close
如果请求或响应中的Connection header被指定为close，表示在当前请求或响应完成后将关闭TCP连接。
The current implementation doesn't buffer the response body. Which means that the application has to finish reading the response body or call close() to abandon the rest of the response body, in order for that connection to be reused. Furthermore, current implementation will not try block-reading when cleaning up the connection, meaning if the whole response body is not available, the connection will not be reused.
JDK中的当前实现不支持缓存响应体，所以应用程序必须读取完响应体内容或者调用close()关闭流并丢弃未读内容来重用连接。此外，当前实现在清理连接时并未使用阻塞读，这就意味这如果响应体不可用，连接将不能被重用。What's new in Tiger?
When the application encounters a HTTP 400 or 500 response, it may ignore the IOException and then may issue another HTTP request. In this case, the underlying TCP connection won't be Kept-Alive because the response body is still there to be consumed, so the socket connection is not cleared, therefore not available for reuse. What the application needs to do is call HttpURLConnection.getErrorStream() after catching the IOException , read the response body, then close the stream. However, some existing applications are not doing this. As a result, they do not benefit from persistent connections. To address this problem, we have introduced a workaround.The workaround involves buffering the response body if the response is >=400, up to a certain amount and within a time limit, thus freeing up the underlying socket connection for reuse. The rationale behind this is that when the server responds with a >=400 error (client error or server error. One example is "404: File Not Found" error), the server usually sends a small response body to explain whom to contact and what to do to recover.
JDK1.5中的新特性
当应用接收到400或500的HTTP响应时，它将忽略IOException 而另发一个HTTP 请求。这种情况下，底层的TCP连接将不会再保持，因为响应内容还在等待被读取，socket 连接未清理，不能被重用。应用可以在捕获IOException 以后调用HttpURLConnection.getErrorStream() ，读取响应内容然后关闭流。但是现存的应用没有这么做，不能体现出长连接的优势。为了解决这个问题，介绍下workaround。
当响应体的状态码大于或等于400的时候，workaround 将在一定时间内缓存一定数量的响应内容，释放底层的socket连接来重用。基本原理是当响应状态码大于或等于400时，服务器端会发送一个简短的响应体来指明连接谁以及如何恢复连接。Several new Sun implementation specific properties are introduced to help clean up the connections after error response from the server.
The major one is:
sun.net.http.errorstream.enableBuffering=<boolean>
default: falseWith the above system property set to true (default is false), when the response code is >=400, the HTTP handler will try to buffer the response body. Thus freeing up the underlying socket connection for reuse. Thus, even if the application doesn't call getErrorStream(), read the response body, and then call close(), the underlying socket connection may still be kept-alive and reused.
The following two system properties provide further control to the error stream buffering behavior.:
sun.net.http.errorstream.timeout=<int> in millisecond
default: 300 millisecondsun.net.http.errorstream.bufferSize=<int> in bytes
default: 4096 bytes下面介绍一些SUN实现中的特定属性来帮助接收到错误响应体后清理连接：
主要的一个是：
sun.net.http.errorstream.enableBuffering=<布尔值>
默认: false当上面属性设置为true后，在接收到响应码大于或等于400是，HTTP 句柄将尝试缓存响应内容。释放底层的socket连接来重用。所以，即便应用不调用getErrorStream()来读取响应内容，或者调用 close()关闭流，底层的socket连接也将保持连接状态。
下面的两个系统属性是为了更进一步控制错误流的缓存行为：
sun.net.http.errorstream.timeout=<int> in 毫秒
默认: 300 毫秒sun.net.http.errorstream.bufferSize=<int> in bytes
默认: 4096 bytes
What can you do to help with Keep-Alive?
Do not abandon a connection by ignoring the response body. Doing so may results in idle TCP connections. That needs to be garbage collected when they are no longer referenced.If getInputStream() successfully returns, read the entire response body.
When calling getInputStream() from HttpURLConnection, if an IOException occurs, catch the exception and call getErrorStream() to get the response body (if there is any).
Reading the response body cleans up the connection even if you are not interested in the response content itself. But if the response body is long and you are not interested in the rest of it after seeing the beginning, you can close the InputStream. But you need to be aware that more data could be on its way. Thus the connection may not be cleared for reuse.
Here's a code example that complies to the above recommendation:
你如何做可以保持连接为连接状态呢？
不要忽略响应体而丢弃连接。这样会是TCP连接闲置，当不再被引用后将会被垃圾回收器回收。
如果getInputStream()返回成功，读取全部响应内容。如果抛出IOException ，捕获异常并调用getErrorStream() 读取响应内容（如果存在响应内容）。
即便你对响应内容不感兴趣，也要读取它，以便清理连接。但是，如果响应内容很长，你读取到开始部分后就不感兴趣了，可以调用close()来关闭流。值得注意的是，其他部分的数据已在读取中，所以连接将不能被清理进而被重用。
下面是一个基于上面建议的代码样例：1
try 
{
2
URL a = new URL(args[0]);
3 URLConnection urlc = a.openConnection();
4 is = conn.getInputStream();
5 int ret = 0;
6
while ((ret = is.read(buf)) > 0) {
7 processBuf(buf);
8
}
9 // close the inputstream
10 is.close();
11} catch (IOException e) {
12 try {
13 respCode = ((HttpURLConnection)conn).getResponseCode();
14 es = ((HttpURLConnection)conn).getErrorStream();
15 int ret = 0;
16 // read the response body
17 while ((ret = es.read(buf)) > 0) {
18 processBuf(buf);
19 }
20 // close the errorstream
21 es.close();
22 } catch(IOException ex) {
23 // deal with the exception
24 }
25
}
If you know ahead of time that you won't be interested in the response body, you should issue a HEAD request instead of a GET request. For example when you are only interested in the meta. info of the web resource or when testing for its validity, accessibility and recent modification. Here's a code snippet:
如果你预先就对响应内容不感兴趣，你可以使用HEAD 请求来代替GET 请求。例如，获取web资源的meta信息或者测试它的有效性，可访问性以及最近的修改。下面是代码片段：1
URL a = new URL(args[0]);
2URLConnection urlc = a.openConnection();
3HttpURLConnection httpc = (HttpURLConnection)urlc;
4// only interested in the length of the resource
5httpc.setRequestMethod("HEAD");
6int len = httpc.getContentLength();
根据前面的图可以知道，Keep Alive 属性有服务端和客户端两头都可以设置，
那么服务器端如何设置才可以获得更好的性能呢？8.Apache 中 Keep Alive 配置的合理使用——里面的公式和计算方法，没看懂，不要迷信还是要实证
http://blog.163.com/hai_zone/blog/static/264611372010718103838356/?fromdm&fromSearch&isFromSearchEngine=yes在 Apache 服务器中，KeepAlive 是一个布尔值，On 代表打开，Off 代表关闭，这个指令在其他众多的 HTTPD 服务器中都是存在的。
KeepAlive 配置指令决定当处理完用户发起的 HTTP 请求后是否立即关闭 TCP 连接，如果 KeepAlive 设置为On，那么用户完成一次访问后，不会立即断开连接，如果还有请求，那么会继续在这一次 TCP 连接中完成，而不用重复建立新的 TCP 连接和关闭TCP 连接，可以提高用户访问速度。
那么我们考虑3种情况：
1。用户浏览一个网页时，除了网页本身外，还引用了多个 javascript. 文件，多个 css 文件，多个图片文件，并且这些文件都在同一个 HTTP 服务器上。
2。用户浏览一个网页时，除了网页本身外，还引用一个 javascript. 文件，一个图片文件。
3。用户浏览的是一个动态网页，由程序即时生成内容，并且不引用其他内容。对于上面3中情况，我认为：1 最适合打开 KeepAlive ，2 随意，3 最适合关闭 KeepAlive
下面我来分析一下原因。
在 Apache 中，打开和关闭 KeepAlive 功能，服务器端会有什么异同呢？
先看看理论分析。
打开 KeepAlive 后，意味着每次用户完成全部访问后，都要保持一定时间后才关闭会关闭 TCP 连接，那么在关闭连接之前，必然会有一个Apache 进程对应于该用户而不能处理其他用户，假设 KeepAlive 的超时时间为 10 秒种，服务器每秒处理 50个独立用户访问，那么系统中 Apache 的总进程数就是 10 * 50 ＝ 500 个，如果一个进程占用 4M 内存，那么总共会消耗 2G内存，所以可以看出，在这种配置中，相当消耗内存，但好处是系统只处理了 50次 TCP 的握手和关闭操作。
如果关闭 KeepAlive，如果还是每秒50个用户访问，如果用户每次连续的请求数为3个，那么 Apache 的总进程数就是 50 * 3= 150 个，如果还是每个进程占用 4M 内存，那么总的内存消耗为 600M，这种配置能节省大量内存，但是，系统处理了 150 次 TCP的握手和关闭的操作，因此又会多消耗一些 CPU 资源。
在看看实践的观察。
我在一组大量处理动态网页内容的服务器中，起初打开 KeepAlive功能，经常观察到用户访问量大时Apache进程数也非常多，系统频繁使用交换内存，系统不稳定，有时负载会出现较大波动。关闭了 KeepAlive功能后，看到明显的变化是： Apache 的进程数减少了，空闲内存增加了，用于文件系统Cache的内存也增加了，CPU的开销增加了，但是服务更稳定了，系统负载也比较稳定，很少有负载大范围波动的情况，负载有一定程度的降低；变化不明显的是：访问量较少的时候，系统平均负载没有明显变化。
总结一下：
在内存非常充足的服务器上，不管是否关闭 KeepAlive 功能，服务器性能不会有明显变化；
如果服务器内存较少，或者服务器有非常大量的文件系统访问时，或者主要处理动态网页服务，关闭 KeepAlive 后可以节省很多内存，而节省出来的内存用于文件系统Cache，可以提高文件系统访问的性能，并且系统会更加稳定。
补充1：
关于是否应该关闭 KeepAlive 选项，我觉得可以基于下面的一个公式来判断。在理想的网络连接状况下，系统的 Apache 进程数和内存使用可以用如下公式表达：
HttpdProcessNumber = KeepAliveTimeout * TotalRequestPerSecond / Average(KeepAliveRequests)
HttpdUsedMemory = HttpdProcessNumber * MemoryPerHttpdProcess换成中文：
总Apache进程数 = KeepAliveTimeout * 每秒种HTTP请求数 / 平均KeepAlive请求
Apache占用内存 = 总Apache进程数 * 平均每进程占用内存数需要特别说明的是：
[平均KeepAlive请求] 数，是指每个用户连接上服务器后，持续发出的 HTTP 请求数。当 KeepAliveTimeout 等 0或者 KeepAlive 关闭时，KeepAliveTimeout 不参与乘的运算从上面的公式看，如果 [每秒用户请求]多，[KeepAliveTimeout] 的值大，[平均KeepAlive请求] 的值小，都会造成 [Apache进程数] 多和 [内存]多，但是当 [平均KeepAlive请求] 的值越大时，[Apache进程数] 和 [内存] 都是趋向于减少的。基于上面的公式，我们就可以推算出当 平均KeepAlive请求 <= KeepAliveTimeout 时，关闭 KeepAlive 选项是划算的，否则就可以考虑打开。
补充2: KeepAlive 该参数控制Apache是否允许在一个连接中有多个请求，默认打开。但对于大多数论坛类型站点来说，通常设置为off以关闭该支持。
补充3: 如果服务器前跑有应用squid服务，或者其它七层设备,KeepAlive On 设定要开启持续长连接
实际在 前端有 squid 的情况下, KeepAlive 很关键。记得 On
9.不可忽略的KeepAlive —— Apache 中 Keep Alive 配置
http://tomyz0223.iteye.com/blog/603187在网页开发过程中，Keep-Alive是HTTP协议中非常重要的一个属性。大家知道HTTP构建在TCP之上。在HTTP早期实现中，每个HTTP请求都要打开一个socket连接。这种做效率很低，因为一个Web 页面中的很多HTTP请求都指向同一个服务器。例如，很多为Web页面中的图片发起的请求都指向一个通用的图片服务器。持久连接的引入解决了多对已请求服务器导致的socket连接低效性的问题。它使浏览器可以再一个单独的连接上进行多个请求。浏览器和服务器使用Connection头ilai指出对 Keep-Alive的支持。
笔者在去年遇到一个跟Keep-Alive的问题：
问题现象： 一个JSP页面，居然要耗时40多秒。网页中有大量的图片的CSS
问题解决： 原因也找了半天，原来Apache配置里面，把Keep-Alive的开关关闭了。这个是个大问题，工程师为什么要关闭它，原来他考虑的太简单了，我们知道Apache适合处于短连接的请求，处理时间越短，并发数才能上去，原来他是这么考虑，但是没有办法，只能这样了，还是打开Keep-Alive开关吧。
当然，不是所有的情况都设置KeepAlive为On，下面的文字总结比较好：
【在使用apache 的过程中，KeepAlive 属性我一直保持为默认值On，其实，该属性设置为On还是Off还是要具体问题具体分析的，在生产环境中的影响还是蛮大的。
KeepAlive 选项到底有什么用处？如果你用过Mysql ，应该知道Mysql的连接属性中有一个与KeepAlive 类似的Persistent Connection，即：长连接(PConnect)。该属性打开的话，可以使一次TCP连接为同一用户的多次请求服务，提高了响应速度。
比如很多网页中图片、CSS、JS、Html都在一台Server上，当用户访问其中的Html网页时，网页中的图片、Css、Js都构成了访问请求，打开KeepAlive 属性可以有效地降低TCP握手的次数(当然浏览器对同一域下同时请求的图片数有限制，一般是2)，减少httpd进程数，从而降低内存的使用(假定prefork模式)。MaxKeepAliveRequests 和KeepAliveTimeOut 两个属性在KeepAlive =On时起作用，可以控制持久连接的生存时间和最大服务请求数。
不过，上面说的只是一种情形，那就是静态网页居多的情况下，并且网页中的其他请求与网页在同一台Server上。当你的应用动态程序(比如：php )居多，用户访问时由动态程序即时生成html内容，html内容中图片素材和Css、Js等比较少或者散列在其他Server上时，KeepAlive =On反而会降低Apache 的性能。为什么呢？
前面提到过，KeepAlive =On时，每次用户访问，打开一个TCP连接，Apache 都会保持该连接一段时间，以便该连接能连续为同一client服务，在KeepAliveTimeOut还没到期并且MaxKeepAliveRequests还没到阈值之前，Apache 必然要有一个httpd进程来维持该连接，httpd进程不是廉价的，他要消耗内存和CPU时间片的。假如当前Apache 每秒响应100个用户访问，KeepAliveTimeOut=5，此时httpd进程数就是100*5=500个(prefork 模式)，一个httpd进程消耗5M内存的话，就是500*5M=2500M=2.5G，夸张吧？当然，Apache 与Client只进行了100次TCP连接。如果你的内存够大，系统负载不会太高，如果你的内存小于2.5G，就会用到Swap，频繁的Swap切换会加重CPU的Load。
现在我们关掉KeepAlive ，Apache 仍然每秒响应100个用户访问，因为我们将图片、js、css等分离出去了，每次访问只有1个request，此时httpd的进程数是100*1=100个，使用内存100*5M=500M，此时Apache 与Client也是进行了100次TCP连接。性能却提升了太多。
总结：
1、当你的Server内存充足时，KeepAlive =On还是Off对系统性能影响不大。
2、当你的Server上静态网页(Html、图片、Css、Js)居多时，建议打开KeepAlive 。
3、当你的Server多为动态请求(因为连接数据库，对文件系统访问较多)，KeepAlive 关掉，会节省一定的内存，节省的内存正好可以作为文件系统的Cache(vmstat命令中cache一列)，降低I/O压力。
PS：当KeepAlive =On时，KeepAliveTimeOut的设置其实也是一个问题，设置的过短，会导致Apache 频繁建立连接，给Cpu造成压力，设置的过长，系统中就会堆积无用的Http连接，消耗掉大量内存，具体设置多少，可以进行不断的调节，因你的网站浏览和服务器配置 而异。
10. HTTP协议中的持久连接connection:keep-alive，的一些问题和思考，参考。
http://www.51sea.com/cache/water/587.html关于keep-alive这个东西，是否要开放，对性能究竟有何影响，目前大家估计也都是从经验方面来设置的，没有从理论层面的讨论，今天我来挖个坑，希望大家踊跃往里跳。
简单整理一下问题要点：
1，keep-alive的工作原理是什么，能解决什么问题？
2，web server设置了keep-alive，是否需要下级协议盏的支持才起作用？例如是否要启用tcp/ip的keep alive机制？
3，web server设置了keep-alive，是否要客户端浏览器有相应支持？是否要客户端协议盏的支持？如果要得话，我们通常使用的各种系统以及各种浏览器支持的情况怎样？
4，keep-alive会带来性能提升吗？具体体现在什么方面？例如可承载高并发访问？或者是可提升传输性能？再或者可减轻服务器压力？在低访问量和高访问量情况下有何区别？
就我个人的理解来看，keep-alive是利用了tcp的双向全双工连接特性，在web-server端可以不断开连接，来接受客户端更多的请求，应该是能够改善连接时间，不过似乎在连接非常多的情况下会大大加重服务器负担，需要tcp/ip协议盏支持，并且不同客户端之间有不同的设定，具体细节还不详。
楼上的文章受教了，简单说就是从http协议的情况来看，默认1.0是关闭的，需要在http头加入Connection: Keep-Alive才能发起keep-alive的连接，而http1.1协议默认启用keep-alive，如果加入Connection: close 则就强制关闭。
目前大部分浏览器都是用http1.1协议，也就是说默认都会发起keep-alive的连接请求了，所以是否能完成一个完整的keep-alive连接就看服务器设置情况。我推测服务器返回的http头应该包含关于keep-alive的信息，回去抓包正是一下。
楼上的文章说我在网上找到的，事实上服务器确实会返回关于keep-alive的消息。最简单的方法，不需要任何额外的软件，你可以打开迅雷，随便下载一个文件，然后查看任务详情里面，他就有http请求和回应的header信息，从这个里面可以清楚的看到客户端在header设置了keep- alive，而服务器返回时也有这个header字段。
不过我刚开始还在担心一个问题，他是怎么保持连接的呢？既然说到http是无状态的，那server根本就不知道这个连接建立多久了，如果数据已经传送完毕，那客户端应该不会继续想server请求了吧？既然没有数据交互，也没有状态信息，那怎么保持甚至是结束这个连接呢？至少我在网上看到的答案是这个连接是不能保持很久的，一般最多空闲两分钟而已。这么来看还是可以接受的。
另外一个问题是，网上关于这方面的资料好像很少，至少中文的是这样，百度googlge不到。但是实际上《计算机网络--自顶向下方法与internet 特色》这本书是讲得很清楚的。在中译本P60或原版P89就有十分详细生动的解释，这里没有时间把他写上来了。当然，书中的一个不足是没有在那里提到这个持久连接是在header中设置connection字段来实现的，当然了，这也是因为那个时候书上还没有讲到http header的结构。
11. FireFox下的HTTP请求构造调试工具Tamper
Tamper是firefox下的HTTP请求监听和调试工具，功能和Fiddler差不多，但用起来比Fiddler更加方便，毕竟是firefox下的扩展。同样的，
可以对请求进行拦截，修改请求头和请求参数等信息，方便进行程序调试和问题监控。可以从这里下载：https://addons.mozilla.org/zh-CN/firefox/addon/966/
直接在"附加插件"里搜索Tamper吧：
参考文章汇总：1.HTTP无状态协议和Connection:Keep-Alive容易犯的误区
http://liuzhigong.blog.163.com/blog/static/178272375201141344312315/2. http长连接与短连接——可以了解下常见的通信场景
http://www.cnblogs.com/Roberts/archive/2010/12/05/1986550.html3. http长连接技术文章翻译——关于http长连接有很多重要的概念
http://www.blogjava.net/xjacker/articles/334709.html4.Apache 中 Keep Alive 配置的合理使用——里面的公式和计算方法，没看懂，不要迷信还是要实证
http://blog.163.com/hai_zone/blog/static/264611372010718103838356/?fromdm&fromSearch&isFromSearchEngine=yes5.不可忽略的KeepAlive —— Apache 中 Keep Alive 配置
http://tomyz0223.iteye.com/blog/6031876.HTTP协议中的持久连接connection:keep-alive，的一些问题和思考，参考。
http://www.51sea.com/cache/water/587.html图片和文章附件：
loadrunner_http长连接设置.rar(1.39 MB) -
正则表达式笔记及正则表达式30分钟入门教程
2011-07-18 17:01:09
-
很多游戏统计数据里的数值mau，dau之类，是什么意思
2011-07-18 14:13:36
DAU=daily active users
MAU=monthly active users本周DAU上升最快Facebook游戏排行榜 2011年01月13日
-
测试blog推荐
2011-07-18 11:00:50
-
503错误
2011-07-12 16:57:23
503错误
原因：
1. 当请求到达时应用程序池时队列已满，和应用服务器的请求队列限制appRequestQueueLimit属性设置的值太低有关，需要调整应用服务器的配置，调高请求队列的上限，等待时间
2. 调用底层接口超时，（调用底层接口超时，调用接口会做一定的处理，会主动关闭请求链接；有重试次数设置的，超过重试次数也可能会关闭）
简介
503是一种HTTP状态码。英文名503 Service Unavailable与404（404 Service Unavailable)是同属一种网页状态出错码。前者是服务器出错的一种返回状态，后者是网页程序没有相关结果后返回的一种状态，需要优化网站的时候通常须要制作404出错页已便网站整体优化。 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After起头用以标明这个延迟时间。如果没有给出这个 Retry-After信息，那么客户端应当以处理500（Server Internal Error)响应的方式处理它。注意：503状态码的存在并不意味着服务器在过载的时候必须使用它。某些服务器只不过是希望拒绝客户端的连接。
分析：
出现503错误，其日志都是记录在%Systemroot%\System32\LogFiles\HTTPERR\httperr1.log中。
其中的s-reason项：
1、若为AppShutdown，可能是由于CPU占用率太高导致自动关闭应用程序池。
2、若为AppOffline，可能是由于应用程序标识出错引起的。
3、若为Disabled，可能是由管理员手工关闭应用程序池引起的。
4、若为QueueFull，可能是因为请求时应用程序池队列已满而生成该错误。
网页出现503错误原因
网页出现503错误原因：
1、网络管理员可能关闭应用程序池以执行维护。
2、当请求到达时应用程序池队列已满。
3、应用程序池标识没有使用预定义账户：网络服务，而自己配置了标识，但是配置的这个用户不属于IIS_WPG组
4、应用程序池启用了CPU监视，并且设置了CPU利用率超过一定百分比关闭应用程序池，而开发人员写的服务端页面（.asp,.aspx）执行效率不高，会引起CPU的长时间占用，最终达到设置的百分比，从而引起应用程序池关闭
5、应用程序池的性能选项卡的请求队列限制所填的数值太小，默认为1000。
6、web.config的system.web/httpRuntime节点的appRequestQueueLimit属性设置的值太低。
-
traceroute 查看数据包经过的路由信息
2011-07-11 14:43:02
定义
详细解释
Internet，即国际互联网，是目前世界上最大的计算机网络，更确切地说是网络的网络。它由遍布全球的几万局域网和数百万台计算机组成，并通过用于异构网络的TCP/IP协议进行网间通信。互联网中，信息的传送是通过网中许多段的传输介质和设备（路由器，交换机，服务器，网关等等）从一端到达另一端。每一个连接在Internet上的设备，如主机、路由器、接入服务器等一般情况下都会有一个独立的IP地址。通过Traceroute我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点（source）到达某一同样的目的地(destination)走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。UNIX系统中，我们称之为Traceroute,MS Windows中为Tracert。 Traceroute通过发送小的数据包到目的设备直到其返回，来测量其需要多长时间。一条路径上的每个设备Traceroute要测3次。输出结果中包括每次测试的时间(ms)和设备的名称（如有的话）及其IP地址。
例子
在大多数情况下，作为网络工程技术人员或者系统管理员会在UNIX主机系统下，直接执行命令行：
Traceroute hostname
而在Windows系统下是执行Tracert的命令：
Tracert hostname
比如在北京地区使用windows NT 主机（已经与北京163建立了点对点的连接后）
使用NT系统中的Tracert命令：(用户可用：开始;运行,输入"command" 调出command窗口使用此命令）
C:\>tracert www.yahoo.com
Tracing route to www.yahoo.com [204.71.200.75]
over a maximum of 30 hops:
1 161 ms 150 ms 160 ms 202.99.38.67
2 151 ms 160 ms 160 ms 202.99.38.65
3 151 ms 160 ms 150 ms 202.97.16.170
4 151 ms 150 ms 150 ms 202.97.17.90
5 151 ms 150 ms 150 ms 202.97.10.5
6 151 ms 150 ms 150 ms 202.97.9.9
7 761 ms 761 ms 752 ms border7-serial3-0-0.Sacramento.cw.net [204.70.122.69]
8 751 ms 751 ms * core2-fddi-0.Sacramento.cw.net [204.70.164.49]
9 762 ms 771 ms 751 ms border8-fddi-0.Sacramento.cw.net [204.70.164.67]
10 721 ms * 741 ms globalcenter.Sacramento.cw.net [204.70.123.6]
11 * 761 ms 751 ms pos4-2-155M.cr2.SNV.globalcenter.net [206.132.150.237]
12 771 ms * 771 ms pos1-0-2488M.hr8.SNV.globalcenter.net [206.132.254.41]
13 731 ms 741 ms 751 ms bas1r-ge3-0-hr8.snv.yahoo.com [208.178.103.62]
14 781 ms 771 ms 781 ms www10.yahoo.com [204.71.200.75]
Trace complete.
您目前正在ONLINE状态的话，可以直接尝试一下。
参数说明：
tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name
该诊断实用程序通过向目的地发送具有不同生存时间 (TTL) 的 Internet 控制信息协议 (ICMP) 回应报文，以确定至目的地的路由。路径上的每个路由器都要在转发该 ICMP 回应报文之前将其 TTL 值至少减 1，因此 TTL 是有效的跳转计数。当报文的 TTL 值减少到 0 时，路由器向源系统发回 ICMP 超时信息。通过发送 TTL 为 1 的第一个回应报文并且在随后的发送中每次将 TTL 值加 1，直到目标响应或达到最大 TTL 值，Tracert 可以确定路由。通过检查中间路由器发发回的 ICMP 超时 (ime Exceeded) 信息，可以确定路由器。注意，有些路由器“安静”地丢弃生存时间 (TLS) 过期的报文并且对 tracert 无效。
参数
-d
指定不对计算机名解析地址。
-h maximum_hops
指定查找目标的跳转的最大数目。
-jcomputer-list
指定在 computer-list 中松散源路由。
-w timeout
等待由 timeout 对每个应答指定的毫秒数。
target_name
目标计算机的名称。
工作原理
Traceroute最简单的基本用法是：traceroute hostname
Traceroute程序的设计是利用ICMP及IP header的TTL（Time To Live）栏位（field）。首先，traceroute送出一个TTL是1的IP datagram（其实，每次送出的为3个40字节的包，包括源地址，目的地址和包发出的时间标签）到目的地，当路径上的第一个路由器（router）收到这个datagram时，它将TTL减1。此时，TTL变为0了，所以该路由器会将此datagram丢掉，并送回一个「ICMP time exceeded」消息（包括发IP包的源地址，IP包的所有内容及路由器的IP地址），traceroute 收到这个消息后，便知道这个路由器存在于这个路径上，接着traceroute 再送出另一个TTL是2 的datagram，发现第2 个路由器...... traceroute 每次将送出的datagram的TTL 加1来发现另一个路由器，这个重复的动作一直持续到某个datagram 抵达目的地。当datagram到达目的地后，该主机并不会送回ICMP time exceeded消息，因为它已是目的地了，那么traceroute如何得知目的地到达了呢？
Traceroute在送出UDP datagrams到目的地时，它所选择送达的port number 是一个一般应用程序都不会用的号码（30000 以上），所以当此UDP datagram 到达目的地后该主机会送回一个「ICMP port unreachable」的消息，而当traceroute 收到这个消息时，便知道目的地已经到达了。所以traceroute 在Server端也是没有所谓的Daemon 程式。
Traceroute提取发 ICMP TTL到期消息设备的IP地址并作域名解析。每次 ，Traceroute都打印出一系列数据,包括所经过的路由设备的域名及 IP地址,三个包每次来回所花时间。
Traceroute 有一个固定的时间等待响应(ICMP TTL到期消息)。如果这个时间过了，它将打印出一系列的*号表明：在这个路径上，这个设备不能在给定的时间内发出ICMP TTL到期消息的响应。然后，Traceroute给TTL记数器加1，继续进行。参见traceroute仿真动画[1].
网关
一般使用Traceroute(或者是Tracert)是基于一台主机的，但是通常您只能知道以手边的主机为源地址到互联网络上任意一台在线的主机的路由连接质量以及数据传输效率的情况，而使用基于WEB的方式，只要一台主机安装了特定的CGI程序，用户就可以通过这台主机运行相关的程序，执行Traceroute的功能。这台主机我们把它叫做Traceroute网关。Traceroute网关可以帮助用户了解网络的物理与逻辑连接的拓扑情况以及数据传输的效率。如果这种网关足够多，我们就可以方便地了解到各主机之间连接的情况了。
原理
1.几乎每一个网上人（尤其是Webmaster）对他们的计算机（或其它设备）与Internet的连接，路由（径），连通时间，速度等都很关心。使用由ChianNetMap组织起来的各地区Webmaster提供的Traceroute网关的服务，将给你一个满意的答案。从你的计算机到任何别的地方，ChinaNetMap(Traceroute)都能提供其间的每个设备（IP地址）及其连通时间。它可以让你画出通过网络的路径。
2.许多公司和单位都设有或正在设立自己的服务器-尤其是Web服务器。一旦有自己的Web服务器，随着网民数量的日益增加（包括潜在的，没法统计的网民），你一定很想知道是否他们都能与你连接。你的ISP如何与一个或多个NAP连接,以及他们的连接效率会直接影响到你的连接质量.
3.在选择ISP，骨干网连接，你站点的主机时，大多数有见识的网民喜欢检查该Site的连接性能及其它是怎样精确的与谁连，连到哪儿。ChinaNetMap（Traceroute）将给你一个完美的答案。
功能
Traceroute最早是由Van Jacobson在1988写出的小程序。当时主要是解决他自己碰到的一些网络的问题。Traceroute是一个正确理解IP网络并了解路由原理的重要工具。他们对负责网络工程技术与系统管理的Webmaster是一个使用方便的程序。
对ISP而言，设立Traceroute网关，将使网络服务提供商帮助用户建立并维持对服务商服务质量的信心。服务质量高的ISP可以通过设立Traceroute网关，使用户了解其与网络连接以及数据传输的效率。当然，基础设施差，服务质量低的ISP是比较害怕提供这种服务。因为，这样用户可以使用这一工具了解服务商目前的网络连接情况。
在一台主机安装了相关的Traceroute的CGI程序后，您可以输入相应的目的主机的IP地址或者名字，就可以得到相关的数据：
如：在美国的主机http://bs.mit.edu:8001/cgi-bin/traceroute上
查询其到中国南京的北极星站点www.lodesoft.com(中国Webmaster联盟的合作伙伴）数据传输的路径。
查询界面为：
Traceroute Hack
可以搜索该索引。请键入要搜索的关键字:
查询结果为：
Traceroute Hack
1 E40-RTR-E40SERVER72-ETHER.MIT.EDU (18.72.0.1) 4 ms 4 ms 4 ms
2 EXTERNAL-RTR-FDDI.MIT.EDU (18.168.0.12) 4 ms 4 ms 4 ms
3 f1-0.cambridge2-br2.bbnplanet.net (192.233.33.6) 4 ms 4 ms 4 ms
4 s11-0-1.cambridge1-br1.bbnplanet.net (4.0.1.201) 8 ms 4 ms 4 ms
5 p1-0.cambridge1-nbr2.bbnplanet.net (4.0.1.45) 4 ms 4 ms 4 ms
6 p4-1.bstnma1-ba1.bbnplanet.net (4.0.2.170) 4 ms 4 ms 4 ms
7 p1-0.bstnma1-ba2.bbnplanet.net (4.24.4.194) 4 ms 8 ms 8 ms
8 p2-1.nyc4-nbr3.bbnplanet.net (4.24.4.238) 8 ms 12 ms 12 ms
9 p1-0.nyc4-nbr2.bbnplanet.net (4.0.5.25) 8 ms 12 ms 8 ms
10 p4-0.sanjose1-nbr2.bbnplanet.net (4.0.5.97) 70 ms 70 ms 70 ms
11 p1-0.sanjose1-nbr1.bbnplanet.net (4.0.5.85) 70 ms 70 ms 70 ms
12 p4-0.paloalto-nbr2.bbnplanet.net (4.0.1.1) 70 ms 74 ms 70 ms
13 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) 70 ms 74 ms 74 ms
14 h1-0.atteasylink.bbnplanet.net (4.1.142.254) 74 ms 74 ms 78 ms
15 199.37.127.234 (199.37.127.234) 78 ms 74 ms 78 ms
16 205.174.74.170 (205.174.74.170) 230 ms 238 ms 227 ms
17 202.97.9.65 (202.97.9.65) 238 ms 231 ms 223 ms
18 * 202.97.9.49 (202.97.9.49) 234 ms *
19 202.97.10.110 (202.97.10.110) 246 ms 250 ms *
20 202.97.24.178 (202.97.24.178) 234 ms 238 ms 238 ms
21 202.102.24.74 (202.102.24.74) 234 ms 254 ms *
命令参数
Traceroute的用法为: Traceroute [options] <IP-address or domain-name> [data size]
[options]的内容有:
[-n]:显示的地址是用数字表示而不是符号
[-v]:长输出
[-p]:UDP端口设置(缺省为33434)
[-q]:设置TTL测试数目(缺省为3)
[-t]:设置测包的服务类型
[data size]:每次测试包的数据字节长度(缺省为38)
ICMP的应用--Traceroute
Traceroute是用来侦测主机到目的主机之间所经路由情况的重要工具，也是最便利的工具。前面说到，尽管ping工具也可以进行侦测，但是，因为ip头的限制，ping不能完全的记录下所经过的路由器。所以Traceroute正好就填补了这个缺憾。
Traceroute的原理是非常非常的有意思，它受到目的主机的IP后，首先给目的主机发送一个TTL=1（还记得TTL是什么吗？）的UDP(后面就 知道UDP是什么了)数据包，而经过的第一个路由器收到这个数据包以后，就自动把TTL减1，而TTL变为0以后，路由器就把这个包给抛弃了，并同时产生 一个主机不可达的ICMP数据报给主机。主机收到这个数据报以后再发一个TTL=2的UDP数据报给目的主机，然后刺激第二个路由器给主机发ICMP数据 报。如此往复直到到达目的主机。这样，traceroute就拿到了所有的路由器ip。从而避开了ip头只能记录有限路由IP的问题。
有人要问，我怎么知道UDP到没到达目的主机呢？这就涉及一个技巧的问题，TCP和UDP协议有一个端口号定义，而普通的网络程序只监控少数的几个号码较 小的端口，比如说80,比如说23,等等。而traceroute发送的是端口号>30000(真变态)的UDP报，所以到达目的主机的时候，目的 主机只能发送一个端口不可达的ICMP数据报给主机。主机接到这个报告以后就知道，主机到了，所以，说Traceroute是一个骗子一点也不为过:)
Traceroute程序里面提供了一些很有用的选项，甚至包含了IP选路的选项，请察看man文档来了解这些，这里就不赘述了。
- 参考资料
-
- 1
- 扩展阅读：
-
- 1
Traceroute - 实例仿真演示http://www.visualland.net/view.php?cid=1127&protocol=ICMP&title=6.%20Traceroute&ctype=1
- 1
转自：http://baike.baidu.com/view/70478.htm
TraceRoute(tracert)实现原理TraceRoute程序的实现主要涉及IP头部生存时间（time to live, TTL）字段的使用。设置TTL字段的目的是为了防止数据报由于选路错误或其他软硬件原因从而导致在网络中无休止的流动，TTL字段指定了数据报的生存时间。TTL的初始值由源主机设置，当一份数据报经过路由器时，处理该数据报的路由器都需要把TTL值减去数据报在路由器中停留的秒数。但事实上大多数路由器只是简单地将TTL值减1，因此TTL字段最终被实现为一个跳站计数器。当TTL字段的值被减为0时，路由器就不会转发该数据报，而是将其丢弃，并产生一份ICMP超时差错报文发往源主机以通知错误的发生。TraceRoute程序的关键就在于返回的这份ICMP超时差错报文的源地址就是途经路由器的IP地址。由此，通过依次递增TTL字段的值，就可以得到一份数据报在其传输路径上所经过的路由信息。TraceRoute程序在具体实现时，是令其向目的主机发送一个ICMP回显请求（Echo request）消息，并重复递增IP头部TTL字段的值。刚开始的时候TTL等于1，这样当该数据报抵达途中的第一个路由器时，TTL的值就被减为0，导致发生超时错误，因此该路由器生成一份ICMP超时差错报文返回给源主机。随后，主机将数据报的TTL值递增1，以便IP报文能传递到下一个路由器，下一个路由器将会生成ICMP超时超时差错报文返回给源主机。不断重复这个过程，直到数据报到达最终的目的主机，此时目的主机将返回ICMP回显应答（Echo replay）消息。这样，源主机只需对返回的每一份ICMP报文进行解析处理，就可以掌握数据报从源主机到达目的主机途中所经过的路由信息。 -
linux command-date -r file.txt显示文件最后一次修改日期
2011-07-05 10:29:15
date -r 11.txt "+%Y$1%m$1%d %H:%M:%S"
查看访问日志， grep -v 去除返回200的
tail -f test.com-access_log | grep -v " 200 "
-
最好用的PDF解密软件
2011-06-30 15:12:10
最好用的PDF解密软件:
pdf解密工具.rar(532 KB) -
Java Service Wrapper使用说明-将java变为本地service
2011-06-30 11:37:04
-
linux time命令
2011-06-23 12:59:18
-
jconsole监控tomcat配置
2011-06-16 17:13:36
-
curl命令详解
2011-06-13 18:29:07
-
Google Selenium framework
2011-06-13 18:27:05
-
测试？资深？管理？你伤不起！！！ 与 组织定律：彼得原则、墨菲原则、帕金森定律
2011-06-12 18:29:06
-
Linux中find 02: Linux文件查找命令find,xargs详述
2011-06-12 17:17:24
-
十六个暴有名气的美国新闻网站
2011-06-10 14:02:52
-
HTTP_POST_GET_区别详解
2011-06-08 18:22:28
HTTP POST GET 本质区别详解
一 原理区别
一般在浏览器中输入网址访问资源都是通过GET方式；在FORM提交中，可以通过Method指定提交方式为GET或者POST，默认为GET提交
Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE
URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的 GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询 资源信息，而POST一般用于更新 资源信息(个人认为这是GET和POST的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异 )。
根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的 。
1.所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库 查询一样，不会修改，增加数据，不会影响资源的状态。
* 注意：这里安全的含义仅仅是指是非修改信息。
2.幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等 这个概念：
幂等 （idempotent、idempotence）是一个数学或计算机学概念，常见于抽象代数中。
幂等有以下几种定义：
对于单目运算，如果一个运算对于在范围内的所有的一个数多次进行该运算所得的结果和进行一次该运算所得的结果是一样的，那么我们就称该运算是 幂等的。比如绝对值运算就是一个例子，在实数集中，有abs(a) = abs(abs(a)) 。
对于双目运算，则要求当参与运算的两个值是等值的情况下，如果满足运算结果与参与运算的两个值相等，则称该运算幂等，如求两个数的最大值的函 数，有在在实数集中幂等，即max(x,x) = x 。
看完上述解释后，应该可以理解GET幂等的含义了。
但在实际应用中，以上2条规定并没有这么严格。引用别人文章的例子：比如，新闻站点的头版不断更新。虽然第二次请求会返回不同的一批新闻，该 操作仍然被认为是安全的和幂等的，因为它总是返回当前的新闻。从根本上说，如果目标是当用户打开一个链接时，他可以确信从自身的角度来看没有改变资源即 可。
根据HTTP规范，POST表示可能修改变服务器上的资源的请求 。继续引用上面的例子：还是新闻以网站为例，读者对新闻发表自己的评论应该通过POST实现，因为在评论提交后站点的资源已经不同了，或者说资源被修改 了。
上面大概说了一下HTTP规范中，GET和POST的一些原理性的问题。但在实际的做的时候，很多人却没有按照HTTP规范去做，导致这个问 题的原因有很多，比如说：
1.很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单），这样会麻烦一点。
2.对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE。
3.另外一个是，早期的但是Web MVC框架设计者们并没有有意识地将URL当作抽象的资源来看待和设计 。还有一个较为严重的问题是传统的Web MVC框架基本上都只支持GET和POST两种HTTP方法，而不支持PUT和DELETE方法。
* 简单解释一下MVC：MVC本来是存在于Desktop程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MVC的目的是将M和V的实现代码 分离，从而使同一个程序可以使用不同的表现形式。
以上3点典型地描述了老一套的风格（没有严格遵守HTTP规范），随着架构的发展，现在出现REST(Representational State Transfer)，一套支持HTTP规范的新风格，这里不多说了，可以参考《RESTful Web Services》。
二 表现形式区别
搞清了两者的原理区别，我们再来看一下他们实际应用中的区别：
为了理解两者在传输过程中的不同，我们先看一下HTTP协议的格式：
HTTP请求：
<request line>
<headers>
<blank line>
<request-body>]
在HTTP请求中，第一行必须是一个请求行（request line），用来说明请求类型、要访问的资源以及使用的HTTP版本。紧接着是一个首部（header）小节，用来说明服务器要使用的附加信息。在首部之 后是一个空行，再此之后可以添加任意的其他数据[称之为主体（body）]。
GET与POST方法实例：
GET /books/?sex=man&name=Professional HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
Gecko/20050225 Firefox/1.0.1
Connection: Keep-Alive
POST / HTTP/1.1
Host: www.wrox.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6)
Gecko/20050225 Firefox/1.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Connection: Keep-Alive
（----此处空一行----）
name=Professional%20Ajax&publisher=Wiley
有了以上对HTTP请求的了解和示例，我们再来看两种提交方式的区别：
（1）GET提交，请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，多个参数用&连接；例 如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。
POST提交：把提交的数据放置在是HTTP包的包体中。上文示例中红色字体标明的就是实际的传输数据
因此，GET提交的数据会在地址栏中显示出来，而POST提交，地址栏不会改变
(2)传输数据的大小：首先声明：HTTP协议没有对传输的数据大小进行限制，HTTP协议规范也没有对URL长度进行限制。
而在实际开发中存在的限制主要有：
GET:特定浏览器和服务器对URL长度有限制，例如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如 Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。
因此对于GET提交时，传输数据就会受到URL长度的限制。
POST:由于不是通过URL传值，理论上数据不受限。但实际各个WEB服务器会规定对post提交数据大小进行限制，Apache、IIS6都 有各自的配置。
(3)安全性：
.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修 改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器 缓存， (2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击
（4）Http get,post,soap协议都是在http上运行的
1）get：请求参数是作为一个key/value对的序列（查询字符串）附加到URL上的
查询字符串的长度受到web浏览器和web服务器的限制（如IE最多支持2048个字符），不适合传输大型数据集同时，它很不安全
2）post：请求参数是在http标题的一个不同部分（名为entity body）传输的，这一部分用来传输表单信息，因此必须将Content-type设置为:application/x-www-form- urlencoded。post设计用来支持web窗体上的用户字段，其参数也是作为key/value对传输。
但是：它不支持复杂数据类型，因为post没有定义传输数据结构的语义和规则。
3）soap：是http post的一个专用版本，遵循一种特殊的xml消息格式
Content-type设置为: text/xml 任何数据都可以xml化
三 HTTP响应
1．HTTP响应格式：
<status line>
<headers>
<blank line>
[<response-body>]
在响应中唯一真正的区别在于第一行中用状态信息代替了请求信息。状态行（status line）通过提供一个状态码来说明所请求的资源情况。
HTTP响应实例：
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122
＜html＞
＜head＞
＜title＞Wrox Homepage＜/title＞
＜/head＞
＜body＞
＜!-- body goes here --＞
＜/body＞
＜/html＞
2．最常用的状态码有：
◆200 (OK): 找到了该资源，并且一切正常。
◆304 (NOT MODIFIED): 该资源在上次请求之后没有任何修改。这通常用于浏览器的缓存机制。
◆401 (UNAUTHORIZED): 客户端无权访问该资源。这通常会使得浏览器要求用户输入用户名和密码，以登录到服务器。
◆403 (FORBIDDEN): 客户端未能获得授权。这通常是在401之后输入了不正确的用户名或密码。
◆404 (NOT FOUND): 在指定的位置不存在所申请的资源。
四 完整示例：
例子：
HTTP GET
发送
GET /DEMOWebServices2.8/Service.asmx/CancelOrder?UserID=string&PWD=string&OrderConfirmation=string HTTP/1.1
Host: api.efxnow.com
回复
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
HTTP POST
发送
POST /DEMOWebServices2.8/Service.asmx/CancelOrder HTTP/1.1
Host: api.efxnow.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
UserID=string&PWD=string&OrderConfirmation=string
回复
HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<objPlaceOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</objPlaceOrderResponse>
SOAP 1.2
发送
POST /DEMOWebServices2.8/Service.asmx HTTP/1.1
Host: api.efxnow.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrder xmlns="https://api.efxnow.com/webservices2.3">
<UserID>string</UserID>
<PWD>string</PWD>
<OrderConfirmation>string</OrderConfirmation>
</CancelOrder>
</soap12:Body>
</soap12:Envelope>
回复
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<CancelOrderResponse xmlns="https://api.efxnow.com/webservices2.3">
<CancelOrderResult>
<Success>boolean</Success>
<ErrorDescription>string</ErrorDescription>
<ErrorNumber>int</ErrorNumber>
<CustomerOrderReference>long</CustomerOrderReference>
<OrderConfirmation>string</OrderConfirmation>
<CustomerDealRef>string</CustomerDealRef>
</CancelOrderResult>
</CancelOrderResponse>
</soap12:Body>
</soap12:Envelope>
出处：http://blog.csdn.net/gideal_wang/archive/
标题搜索
我的存档
数据统计
- 访问量: 714450
- 日志数: 415
- 图片数: 1
- 文件数: 3
- 建立时间: 2008-12-07
- 更新时间: 2015-07-14
-exec 和 管道符
用 -exec来执行shell命令，和通过管道符|来执行有什么不同？
可不可以忽略 Permission denied的
-bash-3.1$ find /home/f/a -type f -name enen -exec ls -l {} \;
find: /home/f/a/liuyunge: Permission denied
find: /home/f/a/ll1012: Permission denied
find: /home/f/a/hebaidu: Permission denied
find: /home/f/a/ET_SUN: Permission denied
find: /home/f/a/Rory.Lu: Permission denied
-rw-r--r-- 1 lufeng 27108 60 Nov 1 14:24 /home/f/a/lufeng/enen
find: /home/f/a/shenglee2007: Permission denied
find: /home/f/a/zlh750620: Permission denied
find: /home/f/a/mlh720goodboy: Permission denied
-mtime +n
-mtime +n -n
"用减号-来限定更改时间在距今n日以内的文件，而用加号+来限定更改时间在距今n日以前的文件"
疑问：用加号+来限定更改时间在距今 (n+1) 日以前的文件
very good.Thanks
very good.Thanks
很好的文章
谢谢，又学到一些东西
非常感谢，很实用的文档
非常感谢，很实用的文档，对俺很有帮助哟。
如-007就相当于777，-006相当于666 有误
-007应该是至少007的意思：如：407，447 etc
man，find有详细的例子，-007是的确至少007的意思
我查看了man，find有详细的例子，-007是的确至少007的意思。
而且 -perm +mode 是老的用法，新用法是 find -perm /mode.手册上说他们作用是一样的。
-exec后边的{}有问题
{}之间没有空格吧.页面上的命令有空格,复制粘贴后是错误的.
这里的确有问题
debian:~# find /usr/bin -type f -size -50c -exec 'ls -l' {} ;
find: missing argument to `-exec'
debian:~# find /usr/bin -type f -size -50c -exec ls -l '{}' ';'
-rwxr-xr-x 1 root root 30 2003-11-08 21:31 /usr/bin/rgrep
-rwxr-xr-x 1 root root 29 2004-11-22 14:09 /usr/bin/bison.yacc
-rwxr-xr-x 1 root root 48 2005-09-04 15:20 /usr/bin/pydoc2.3
-rwxr-xr-x 1 root root 32 2005-05-16 19:02 /usr/bin/gnome-sudo
debian:~# find /usr/bin -type f -size -50c -exec ls -l '{}' \;
-rwxr-xr-x 1 root root 30 2003-11-08 21:31 /usr/bin/rgrep
-rwxr-xr-x 1 root root 29 2004-11-22 14:09 /usr/bin/bison.yacc
-rwxr-xr-x 1 root root 48 2005-09-04 15:20 /usr/bin/pydoc2.3
-rwxr-xr-x 1 root root 32 2005-05-16 19:02 /usr/bin/gnome-sudo
debian:~# find /usr/bin -type f -size -50c -exec ls -l \{\} \;
-rwxr-xr-x 1 root root 30 2003-11-08 21:31 /usr/bin/rgrep
-rwxr-xr-x 1 root root 29 2004-11-22 14:09 /usr/bin/bison.yacc
-rwxr-xr-x 1 root root 48 2005-09-04 15:20 /usr/bin/pydoc2.3
-rwxr-xr-x 1 root root 32 2005-05-16 19:02 /usr/bin/gnome-sudo
在用-exec的时候，command不能用''，而{}和;必须用''，或者\转义。
不错的文章
这样的实用实干的文章越多越好！
非常奇怪的问题！！！！
在RHEL4下有文件：/lib/modules/2.6.9ELsmp/source/include/linux/version.h
但是为何用命令find / -name version.h
或者到目录：/lib/modules/2.6.9ELsmp/下
find . -name version.h
都无法找到上述文件。
但是在：/lib/modules/2.6.9ELsmp/source下
find . -name version.h
却可以找到这个文件。
不知是什么原因？？？？
排版有误？
这么多&line; 应该是|吧
谢谢，已经修复
谢谢，已经修复；
改过了么？ 怎么还有line
7、为了查找当前文件系统中的所有目录并排序；
$ find . -type d &line;sort
非常感谢，全部修正；
非常感谢，全部修正；
在solaris下
在solaris下，不用也不能转义 直接使用 ...... -exec ls -l {} \; 即可.