未来一年的目标是学习前人造轮子。
HTTP系列（二）：连接管理
一.TCP连接
为提供了一条可靠的比特传输管道。从连接一端填入的字节会从另一端以原有的顺序、正确地传送出来。
的数据是通过名为分组(或数据报)的小数据块来发送的。
就是“”这个“协议栈”中的最顶层了。其安全版本就是在和之间插入了一个(称为或的)密码加密层。
要传送一条报文时,会以流的形式将报文数据的内容通过一条打开的连接按序传输。收到数据流之后,会将数据流砍成被称作段的小数据块,并将段封装在分组中,通过因特网进行传输
每个 段都是由分组承载,从一个地址发送到另一个地址的。每个分组中都包括:
一个分组首部(通常为字节);
一个段首部(通常为字节);
一个数据块(个或多个字节)。
首部包含了源和目的地址、长度和其他一些标记。段的首部包含了端口号、控制标记,以及用于数据排序和完整性检查的一些数字值。
二、对TCP性能的考虑
最常见的 相关时延：
1.TIME_WAIT和端口耗尽
当某个 端点关闭连接时,会在内存中维护一个小的控制块,用来记录最近所关闭连接的地址和端口号。这类信息只会维持一小段时间,通常是所估计的最大分段使用期的两倍(称为,通常为分钟)左右,以确保在这段时间内不会创建具有相同地址和端口号的新连接。实际上,这个算法可以防止在两分钟内创建、关闭并重新创建两个具有相同地址和端口号的连接。
（TCP分节可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个分节，迷途的分节在路由器修复后也会被送到最终目的地，这个迟到的迷途分节到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。）
在只有一个客户端和一台 服务器的异常情况下,构建一条连接的个值:&source-IP-address,
source-port, destination-IP-address, destination-port&
其中的 个都是固定的——只有源端口号可以随意改变:&client-IP,
source-port, server-IP, 80&
客户端每次连接到服务器上去时,都会获得一个新的源端口,以实现连接的唯一性。但由于可用源端口的数量有限(比如,个),而且在秒(比如,秒)内连接是无法重用的,连接率就被限制在了次秒。如果再不断进行优化,并且服务器的连接率不高于次秒,就可确保不会遇到端口耗尽问题。
2.延迟确认算法
由于因特网自身无法确保可靠的分组传输(因特网路由器超负荷的话,可以随意丢弃分组),所以实现了自己的确认机制来确保数据的成功传输。
每个 段都有一个序列号和数据完整性校验和。每个段的接收者收到完好的段时,都会向发送者回送小的确认分组。如果发送者没有在指定的窗口时间内收到确认信息,发送者就认为分组已被破坏或损毁,并重发数据。
由于确认报文很小,所以 允许在发往相同方向的输出数据分组中对其进行“捎带”。将返回的确认信息与输出的数据分组结合在一起,可以更有效地利用网络。为了增加确认报文找到同向传输数据分组的可能性,很多栈都实现了一种 “延迟确认”算法。延迟确认算法会在一个特定的窗口时间(通常是~
毫秒)内将输出确认存放在缓冲区中,以寻找能够捎带它的输出数据分组。如果在那个时间段内没有输出数据分组,就将确认信息放在单独的分组中传送。
但是,具有双峰特征的请求-
应答行为降低了捎带信息的可能。当希望有相反方向回传分组的时候,偏偏没有那么多。通常,延迟确认算法会引入相当大的时延。根据所使用操作系统的不同,可以调整或禁止延迟确认算法。
3.TCP慢启动
数据传输的性能还取决于连接的使用期()。连接会随着时间进行自我“调谐”,起初会限制连接的最大速度,如果数据成功传输,会随着时间的推移提高传输的速度。这种调谐被称为慢启动(),用于防止因特网的突然过载和拥塞。
慢启动限制了一个端点在任意时刻可以传输的分组数。简单来说,每成功接收一个分组,发送端就有了发送另外两个分组的权限。如果某个事务有大量数据要发送,是不能一次将所有分组都发送出去的。必须发送一个分组,等待确认;然后可以发送两个分组,每个分组都必须被确认,这样就可以发送四个分组了,以此类推。这种方式被称为“打开拥塞窗口”。
由于存在这种拥塞控制特性,所以新连接的传输速度会比已经交换过一定量数据的、“已调谐”连接慢一些。
4.Nagle算法与TCP_NODELAY
有一个数据流接口,应用程序可以通过它将任意尺寸的数据放入栈中——即使一次只放一个字节也可以!但是,每个段中都至少装载了个字节的标记和首部,所以如果发送了大量包含少量数据的分组,网络的性能就会严重下降。
算法(根据其发明者命名)试图在发送一个分组之前,将大量数据绑定在一起,以提高网络效率。
算法鼓励发送全尺寸(上最大尺寸的分组大约是字节,在因特网上是几百字节)的段。只有当所有其他分组都被确认之后,算法才允许发送非全尺寸的分组。如果其他分组仍然在传输过程中,就将那部分数据缓存起来。只有当挂起分组被确认,或者缓存中积累了足够发送一个全尺寸分组的数据时,才会将缓存的数据发送出去。
算法会引发几种性能问题。首先,小的报文可能无法填满一个分组,可能会因为等待那些永远不会到来的额外数据而产生时延。其次,算法与延迟确认之间的交互存在问题——算法会阻止数据的发送,直到有确认分组抵达为止,但确认分组自身会被延迟确认算法延迟~毫秒。
应用程序常常会在自己的栈中设置参数,禁用算法,提高性能。如果要这么做的话,一定要确保会向写入大块的数据,这样就不会产生一堆小分组了。
三、提高HTTP连接性能的几种方法
并行连接通过多条 连接发起并发的请求。
持久连接重用 连接,以消除连接及关闭时延。
管道化连接通过共享的 连接发起并发的请求。
复用的连接交替传送请求和响应报文(实验阶段)。
1.并行连接
允许客户端打开多条连接,并行地执行多个事务。在这个例子中,并行加载了四幅嵌入式图片,每个事务都有自己的连接。
2.持久连接
客户端经常会打开到同一个站点的连接。比如,一个页面上的大部分内嵌图片通常都来自同一个站点,而且相当一部分指向其他对象的超链通常都指向同一个站点。因此,初始化了对某服务器请求的应用程序很可能会在不久的将来对那台服务器发起更多的请求(比如,获取在线图片)。这种性质被称为站点局部性()。
因此,(以及的各种增强版本)允许设备在事务处理结束之后将连接保持在打开状态,以便为未来的请求重用现存的连接。在事务处理结束之后仍然保持在打开状态的连接被称为持久连接。非持久连接会在每个事务结束之后关闭。持久连接会在不同事务之间保持打开状态,直到客户端或服务器决定将其关闭为止。
重用已对目标服务器打开的空闲持久连接,就可以避开缓慢的连接建立阶段。而且,已经打开的连接还可以避免慢启动的拥塞适应阶段,以便更快速地进行数据的传输。
持久连接与并行连接配合使用可能是最高效的方式。现在,很多应用程序都会打开少量的并行连接,其中的每一个都是持久连接。持久连接有两种类型:比较老
的 “”连接,以及现代的“”连接。
1) keep-alive操作
已经不再使用了,而且在当前的规范中也没有对它的说明了。但浏览器和服务器对握手的使用仍然相当广泛。
实现连接的客户端可以通过包含Connection:
Keep-Alive首部请求将一条连接保持在打开状态。
如果服务器愿意为下一条请求将连接保持在打开状态,就在响应中包含相同的首部。如果响应中没有Connection:
Keep-Alive首部,客户端就认为服务器不支持,会在发回响应报文之后关闭连接。
Keep-Alive首部必须随所有希望保持持久连接的报文一起发送。如果客户端没有发送Connection:
Keep-Alive首部,服务器就会在那条请求之后关闭连接。
2）keep-alive选项
注意,keep-Alive首部只是请求将连接保持在活跃状态。发出请求之后,客户端和服务器并不一定会同意进行会话。它们可以在任意时刻关闭空闲的连接,并可随意限制连接所处理事务的数量。
可以用 Keep-Alive通用首部中指定的、由逗号分隔的选项来调节的行为。
参数timeout是在Keep-Alive响应首部发送的。它估计了服务器希望将连接保持在活跃状态的时间。这并不是一个承诺值。
参数max是在Keep-Alive响应首部发送的。它估计了服务器还希望为多少个事务保持此连接的活跃状态。这并不是一个承诺值。
Keep-Alive首部还可支持任意未经处理的属性,这些属性主要用于诊断和调试。语法为name
[=value]。
Keep-Alive首部完全是可选的,但只有在提供Connection:
Keep-Alive时才能使用它。这里有个Keep-Alive响应首部的例子,这个例子说明服务器最多还会为另外个事务保持连接的打开状态,或者将打开状态保持到连接空闲了分钟之后。
Connection: Keep-AliveKeep-Alive: max=5, timeout=120
3）keep-alive和哑代理
很多老的或简单的代理都是盲中继(),它们只是将字节从一个连接转发到另一个连接中去,不对Connection首部进行特殊的处理。（不理解Connection首部,而且不知道在沿着转发链路将其发送出去之前,应该将该首部删除 ）
(1)在图4-15a中 客户端向代理发送了一条报文,其中包含了Connection:Keep-Alive首部,如果可能的话请求建立一条连接。客户端等待响应,以确定对方是否认可它对信道的请求。
哑代理收到了这条请求,但它并不理解
Connection首部(只是将其作为一个扩展首部对待)。代理不知道是什么意思,因此只是沿着转发链路将报文一字不漏地发送给服务器(图)。但Connection首部是个逐跳首部,只适用于单条传输链路,不应该沿着传输链路向下传输。接下来,就要发生一些很糟糕的事情了。
在图中,经过中继的请求抵达了服务器。当服务器收到经过代理转发的Connection:
Keep-Alive首部时,会误以为代理(对服务器来说,这个代理看起来就和所有其他客户端一样)希望进行对话!对服务器来说这没什么问题——它同意进行对话,并在图中回送了一个Connection:
Keep-Alive响应首部。所以,此时服务器认为它在与代理进行对话,会遵循的规则。但代理却对一无所知。不妙。
在图中,哑代理将服务器的响应报文回送给客户端,并将来自服务器的Connection:
Keep-Alive首部一起传送过去。客户端看到这个首部,就会认为代理同意进行对话。所以,此时客户端和服务器都认为它们在进行对话,但与它们进行对话的代理却对一无所知。
由于代理对一无所知,所以会将收到的所有数据都回送给客户端,然后等待源端服务器关闭连接。但源端服务器会认为代理已经显式地请求它将连接保持在打开状态了,所以不会去关闭连接。这样,代理就会挂在那里等待连接的关闭。
客户端在图中收到了回送的响应报文时,会立即转向下一条请求,在连接上向代理发送另一条请求(参见图)。而代理并不认为同一条连接上会有其他请求到来,请求被忽略,浏览器就在这里转圈,不会有任何进展了。
这种错误的通信方式会使浏览器一直处于挂起状态,直到客户端或服务器将连接超时,并将其关闭为止。
为避免此类代理通信问题的发生,现代的代理都绝不能转发Connection首部和所有名字出现在Connection值中的首部。因此,如果一个代理收到了一个Connection:
Keep-Alive首部,是不应该转发Connection首部,或所有名为Keep-Alive的首部的。
在网景的变通做法是,浏览器会向代理发送非标准的Proxy-Connection扩展首部,而不是官方支持的著名的Connection首部。如果代理是盲中继,它会将无意义的Proxy-Connection首部转发给服务器,服务器会忽略此首部,不会带来任何问题。但如果代理是个聪明的代理(能够理解持久连接的握手动作),就用一个Connection首部取代无意义的Proxy-Connection首部,然后将其发送给服务器,以收到预期的效果。
4）persistent连接
逐渐停止了对连接的支持,用一种名为持久连接()的改进型设计取代了它。持久连接的目的与连接的目的相同,但工作机制更优一些。
与的连接不同,持久连接在默认情况下是激活的。除非特别指明,否则假定所有连接都是持久的。要在事务处理结束之后将连接关闭,应用程序必须向报文中显式地添加一个Connection:close首部。这是与以前的协议版本很重要的区别,在以前的版本中,连接要么是可选的,要么根本就不支持。
客户端假定在收到响应后,除非响应中包含了Connection:
close首部,不然连接就仍维持在打开状态。但是,客户端和服务器仍然可以随时关闭空闲的连接。不发送Connection:
close并不意味着服务器承诺永远将连接保持在打开状态。
3.管道化连接
允许在持久连接上可选地使用请求管道。这是相对于连接的又一性能优化。在响应到达之前,可以将多条请求放入队列。当第一条请求通过网络流向地球另一端的服务器时,第二条和第三条请求也可以开始发送了。在高时延网络条件下,这样做可以降低网络的环回时间,提高性能。
显示了持久连接是怎样消除连接时延,以及管道化请求(参见图)是如何消除传输时延的。
对管道化连接有几条限制：
HTTP无状态协议和Connection:Keep-Alive容易犯的误区
HTTP 2 的新特性
二、Servlet客户端HTTP请求和服务端HTTP响应
Http2.2实现https
关于Http相关具体内容
软件工程之QA管理（好软件系列二）
OkHttp源码解析(二)——整体流程（下）
Nginx系列（二）--模块化
没有更多推荐了，一、什么是长连接
HTTP1.1规定了默认保持长连接（HTTP persistent connection ，也有翻译为持久连接），数据传输完成了保持TCP连接不断开（不发RST包、不四次握手），等待在同域名下继续用这个通道传输数据；相反的就是短连接。
　HTTP首部的Connection: Keep-alive是HTTP1.0浏览器和服务器的实验性扩展，当前的HTTP1.1 RFC2616文档没有对它做说明，因为它所需要的功能已经默认开启，无须带着它，但是实践中可以发现，浏览器的报文请求都会带上它。如果HTTP1.1版本的HTTP请求报文不希望使用长连接，则要在HTTP请求报文首部加上Connection: close。《HTTP权威指南》提到，有部分古老的HTTP1.0
代理不理解Keep-alive，而导致长连接失效：客户端--&代理--&服务端，客户端带有Keep-alive，而代理不认识，于是将报文原封不动转给了服务端，服务端响应了Keep-alive，也被代理转发给了客户端，于是保持了“客户端--&代理”连接和“代理--&服务端”连接不关闭，但是，当客户端第发送第二次请求时，代理会认为当前连接不会有请求了，于是忽略了它，长连接失效。书上也介绍了解决方案：当发现HTTP版本为1.0时，就忽略Keep-alive，客户端就知道当前不该使用长连接。其实，在实际使用中不需要考虑这么多，很多时候代理是我们自己控制的，如Nginx代理，代理服务器有长连接处理逻辑，服务端无需做patch处理，常见的是客户端跟Nginx代理服务器使用HTTP1.1协议&长连接，而Nginx代理服务器跟后端服务器使用HTTP1.0协议&短连接。
在实际使用中，HTTP头部有了Keep-Alive这个值并不代表一定会使用长连接，客户端和服务器端都可以无视这个值，也就是不按标准来，譬如我自己写的HTTP客户端多线程去下载文件，就可以不遵循这个标准，并发的或者连续的多次GET请求，都分开在多个TCP通道中，每一条TCP通道，只有一次GET，GET完之后，立即有TCP关闭的四次握手，这样写代码更简单，这时候虽然HTTP头有Connection:
Keep-alive，但不能说是长连接。正常情况下客户端浏览器、web服务端都有实现这个标准，因为它们的文件又小又多，保持长连接减少重新开TCP连接的开销很有价值。
以前使用/下载，就是短连接，抓包可以看到：1、每一条TCP通道只有一个POST；2、在数据传输完毕可以看到四次握手包。只要不调用curl_easy_cleanup，curl的handle就可能一直有效，可复用。这里说可能，因为连接是双方的，如果服务器那边关掉了，那么我客户端这边保留着也不能实现长连接。
如果是使用windows的WinHTTP库，则在POST/GET数据的时候，虽然我关闭了句柄，但这时候TCP连接并不会立即关闭，而是等一小会儿，这时候是WinHTTP库底层支持了跟Keep-alive所需要的功能：即便没有Keep-alive，WinHTTP库也可能会加上这种TCP通道复用的功能，而其它的网络库像libcurl则不会这么做。以前观察过。
二、长连接的过期时间
客户端的长连接不可能无限期的拿着，会有一个超时时间，服务器有时候会告诉客户端超时时间，譬如：
上图中的Keep-Alive: timeout=20，表示这个TCP通道可以保持20秒。另外还可能有max=XXX，表示这个长连接最多接收XXX次请求就断开。对于客户端来说，如果服务器没有告诉客户端超时时间也没关系，服务端可能主动发起四次握手断开TCP连接，客户端能够知道该TCP连接已经无效；另外TCP还有心跳包来检测当前连接是否还活着，方法很多，避免浪费资源。
三、长连接的数据传输完成识别
使用长连接之后，客户端、服务端怎么知道本次传输结束呢？两部分：1是判断传输数据是否达到了Content-Length指示的大小；2动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后有一个空chunked块，表明本次传输数据结束。更细节的介绍可以看。
四、并发连接数的数量限制
在web开发中需要关注浏览器并发连接的数量，说，客户端与服务器最多就连上两通道，但服务器、个人客户端要不要这么做就随人意了，有些服务器就限制同时只能有1个TCP连接，导致客户端的多线程下载（客户端跟服务器连上多条TCP通道同时拉取数据）发挥不了威力，有些服务器则没有限制。浏览器客户端就比较规矩，，限制了同域名下能启动若干个并发的TCP连接去下载资源。并发数量的限制也跟长连接有关联，打开一个网页，很多个资源的下载可能就只被放到了少数的几条TCP连接里，这就是TCP通道复用（长连接）。如果并发连接数少，意味着网页上所有资源下载完需要更长的时间（用户感觉页面打开卡了）；并发数多了，服务器可能会产生更高的资源消耗峰值。浏览器只对同域名下的并发连接做了限制，也就意味着，web开发者可以把资源放到不同域名下，同时也把这些资源放到不同的机器上，这样就完美解决了。
五、容易混淆的概念——TCP的keep alive和HTTP的Keep-alive
TCP的keep alive是检查当前TCP连接是否活着；HTTP的Keep-alive是要让一个TCP连接活久点。它们是不同层次的概念。
TCP keep alive的表现：
当一个连接“一段时间”没有数据通讯时，一方会发出一个心跳包（Keep Alive包），如果对方有回包则表明当前连接有效，继续监控。
这个“一段时间”可以设置。
WinHttp库的设置：
WINHTTP_OPTION_WEB_SOCKET_KEEPALIVE_INTERVAL
Sets the interval, in milliseconds, to send a keep-alive packet over the connection. The default interval is 30000 (30 seconds). The minimum interval is 15000 (15 seconds). Using WinHttpSetOption to set a value lower than 15000 will return with ERROR_INVALID_PARAMETER.
libcurl的设置：
http://curl.haxx.se/libcurl/c/curl_easy_setopt.html
CURLOPT_TCP_KEEPALIVE
Pass a long. If set to 1, TCP keepalive probes will be sent. The delay and frequency of these probes can be controlled by the CURLOPT_TCP_KEEPIDLE and CURLOPT_TCP_KEEPINTVL
options, provided the operating system supports them. Set to 0 (default behavior) to disable keepalive probes (Added in 7.25.0).
CURLOPT_TCP_KEEPIDLE
Pass a long. Sets the delay, in seconds, that the operating system will wait while the connection is idle before sending keepalive probes. Not all operating
systems support this option. (Added in 7.25.0)
CURLOPT_TCP_KEEPINTVL
Pass a long. Sets the interval, in seconds, that the operating system will wait between sending keepalive probes. Not all operating systems support this option.
(Added in 7.25.0)
CURLOPT_TCP_KEEPIDLE是空闲多久发送一个心跳包，CURLOPT_TCP_KEEPINTVL是心跳包间隔多久发一个。
打开网页抓包，发送心跳包和关闭连接如下：
从上图可以看到，大概过了44秒，客户端发出了心跳包，服务器及时回应，本TCP连接继续保持。到了空闲60秒的时候，服务器主动发起FIN包，断开连接。
六、HTTP 流水线技术
使用了HTTP长连接（HTTP persistent connection ）之后的好处，包括可以使用HTTP 流水线技术（HTTP pipelining，也有翻译为管道化连接），它是指，在一个TCP连接内，多个HTTP请求可以并行，下一个HTTP请求在上一个HTTP请求的应答完成之前就发起。从wiki上了解到这个技术目前并没有广泛使用，使用这个技术必须要求客户端和服务器端都能支持，目前有部分浏览器完全支持，而服务端的支持仅需要：按HTTP请求顺序正确返回Response（也就是请求&响应采用FIFO模式），wiki里也特地指出，只要服务器能够正确处理使用HTTP
pipelinning的客户端请求，那么服务器就算是支持了HTTP pipelining。
由于要求服务端返回响应数据的顺序必须跟客户端请求时的顺序一致，这样也就是要求FIFO，这容易导致Head-of-line blocking：第一个请求的响应发送影响到了后边的请求，因为这个原因导致HTTP流水线技术对性能的提升并不明显（wiki提到，这个问题会在HTTP2.0中解决）。另外，使用这个技术的还必须是幂等的HTTP方法，因为客户端无法得知当前已经处理到什么地步，重试后可能发生不可预测的结果。POST方法不是幂等的：同样的报文，第一次POST跟第二次POST在服务端的表现可能会不一样。
在HTTP长连接的wiki中提到了HTTP1.1的流水线技术对RFC规定一个用户最多两个连接的指导意义：流水线技术实现好了，那么多连接并不能提升性能。我也觉得如此，并发已经在单个连接中实现了，多连接就没啥必要，除非瓶颈在于单个连接上的资源限制迫使不得不多开连接抢资源。
目前浏览器并不太重视这个技术，毕竟性能提升有限。
没有更多推荐了，我们收到很多 google bot的请求。googlebot请求 11不同档案通过 11 HTTP GET 请求,在一个tcp/ip连接。这些get请求( 在同一个 tcp/ip连接中) 通过服务器进行处理并行或者按顺序？还是在服务器上？在这种情况下， Nginx 如何处理这个问题？帮助的thx
时间:17年07月01日原作者:
这些get请求( 在同一个 tcp/ip连接中) 通过服务器进行处理并行或者顺序？它是按顺序处理的。 它称为管道。管道是 HTTP/1.1的一部分，它意味着客户端不必等待当前请求完成，然后再通过持久连接发送下一个请求。 它可以在同一连接上发送多个请求，而无需等待先前请求的响应。 请求是以FIFO方式处理的换句话说，客户端可以发送几个请求序列，服务器应该是发送响应，按照请求被接收到的相同顺序。 因此，如果你在 HTTP/1.1 中使用的服务器是兼容的，那么它应该按顺序处理。
HTTP管道是按顺序发生的。不支持任何类型的HTTP交织。但是，使用流水线，服务器在服务最后一个请求之前可能知道所有请求。 理论上，它可以并行地完成必要的I/O 。虽然 Nginx 不会这么做的。
Copyright (C) 2011 HelpLib All rights reserved. &&tcp服务器连接数多少合适
[问题点数：20分，结帖人burningbloodgg]
本版专家分：0
结帖率 95.76%
CSDN今日推荐
本版专家分：440
本版专家分：1355
本版专家分：19636
本版专家分：0
本版专家分：358065
2013年 荣获名人称号
2011年 总版技术专家分年内排行榜第三2010年 总版技术专家分年内排行榜第三
2012年 总版技术专家分年内排行榜第五
2012年1月 总版技术专家分月排行榜第一
本版专家分：0
本版专家分：146
2017年4月 .NET技术大版内专家分月排行榜第二
本版专家分：0
本版专家分：7055
本版专家分：0
本版专家分：7052
本版专家分：97
本版专家分：0
本版专家分：0
本版专家分：0
匿名用户不能发表回复！|
其他相关推荐
在做性能测试测试时候，如果被测试的系统页面很简单，并且性能很好，这样会导致压力机得tcp链接数不够而导致如下错误：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters\TcpTimedWaitDelay to 30
and HKEY_LOCAL_MACHINE\System\CurrentControlSe
先来看看一些约定俗成的内容。
一个网卡对应一个IP地址
一个IP地址对应65535个端口
一个socket(addr, port)可以接受多个socket连接(accept)
一个端口只能被一个socket监听(listen)
我在面试的时候，被问到过这么一个问题：ipv4协议下，假如主机的资源是无限的，理论上一个网卡能够接受多少个tcp连接？这个问题一开始很容易有个na
1、查看用户单一进程最大文件打开数[root@localhost ~]# ulimit -n
10242、修改/etc/security/limits.conf文件，添加下面两行，[root@localhost ~]# vim /etc/security/limits.conf
* soft nofile 20480
#前面的*表示对所有用户生效，如果只想对单一用户修改则把*改成对应用户即
本文转自http://blog.sina.com.cn/s/blog_6f5bc.html
1、修改用户进程可打开文件数限制
在Linux平台上，无论编写客户端程序还是服务端程序，在进行高并发TCP连接处理时，最高的并发数量都要受到系统对用户单一进程同时可打开文件数量的限制(这是因为系统为每个TCP连接都要创建一个socket句柄，每个socket句柄同时也是一个文
如何在单台服务器上实现百万级长连接，以下是实现该目标进行的一些优化：1.首先需要准备一台大内存的服务器，装上linux系统,比如rehat、centos(内核版本在2.6.25之上)等。
为什么需要大内存，因为每个连接都需要有读写缓存，具体看第二部内容；
为什么内核版本要在2.6.25之上，因为2.6.25内核之前有个 宏定义，定义了最大文件描述符大小为，正好是100...
mysql5.6配置连接池
&br /&主要方法：TcpTimedWaitDelay和MaxUserPort设置 &br /&&br /&描述：确定 TCP/IP 可释放已关闭连接并重用其资源前，必须经过的时间。关闭和释放之间的此时间间隔通称 TIME_WAIT 状态或两倍最大段生命周期（2MSL）状态。此时间期间，重新打开到客户机和服务器的连接的成本少于建立新连接。减少此条目的值允许 TCP/IP 更快地释放已关闭的连接，为新连接提供更多资源。如果运行的应用程序需要快速释放和创建新连接，而且由于 TIME_WAIT 中存在很多连接，
很早微博上一直讨论比较多的问题，这里转载个知乎的答案：单机单网卡最大tcp长连接数真的是65535吗？
作者：许怀远
链接：https://www.zhihu.com/question//answer/
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。TCP四元组(quadruple)的概念，就算培训班出来的也听说过吧？不做解释
转自：http://blog.sina.com.cn/s/blog_6f5bc.html
在做Socket 编程时，我们经常会要问，单机最多可以建立多少个 TCP 连接，本文将介绍如何调整系统参数来调整单机的最大TCP连接数。
Windows 下单机的TCP连接数有多个参数共同决定，下面一一介绍：
最大TCP连接数
[HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \Tcpip \Parameters]