最近协助同事解决了几个问题，也对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/

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: true

Indicates if keep alive (persistent) connections should be supported.
http.maxConnections=<int>
default: 5

Indicates the maximum number of connections per destination to be kept alive at any given time

HTTP header that influences connection persistence is:
Connection: close

If 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: false

With 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 millisecond

sun.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()来关闭流。值得注意的是，其他部分的数据已在读取中，所以连接将不能被清理进而被重用。

下面是一个基于上面建议的代码样例：

 1try {
 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信息或者测试它的有效性，可访问性以及最近的修改。下面是代码片段：

1URL 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

9.不可忽略的KeepAlive —— Apache 中 Keep Alive 配置
http://tomyz0223.iteye.com/blog/603187

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.html

3.  http长连接技术文章翻译——关于http长连接有很多重要的概念
http://www.blogjava.net/xjacker/articles/334709.html

4.Apache 中 Keep Alive 配置的合理使用——里面的公式和计算方法，没看懂，不要迷信还是要实证
http://blog.163.com/hai_zone/blog/static/264611372010718103838356/?fromdm&fromSearch&isFromSearchEngine=yes

5.不可忽略的KeepAlive —— Apache 中 Keep Alive 配置
http://tomyz0223.iteye.com/blog/603187

6.HTTP协议中的持久连接connection:keep-alive，的一些问题和思考，参考。
http://www.51sea.com/cache/water/587.html

图片和文章附件：loadrunner_http长连接设置.rar(1.39 MB)