tcp连接复用(tcp端口复用)

参数：url：目标地址data：要post的数据比如a=1&b=2publicstringGetPostString(stringurl,stringdata){try{byte[]postBytes=Encoding.GetEncoding("utf-8").GetBytes(data);HttpWebRequestmyRequest=(HttpWebRequest)WebRequest.Create(url);myRequest.Method="POST";myRequest.ContentType="text/html";myRequest.ContentLength=postBytes.Length;myRequest.Proxy=null;StreamnewStream=myRequest.GetRequestStream();newStream.Write(postBytes,0,postBytes.Length);newStream.Close();//GetresponseHttpWebResponsemyResponse=(HttpWebResponse)myRequest.GetResponse();using(StreamReaderreader=newStreamReader(myResponse.GetResponseStream(),Encoding.GetEncoding("utf-8"))){stringcontent=reader.ReadToEnd();returncontent;}}catch(System.Exceptionex){returnex.Message;}}

在服务端设置端口复用的选项，如： setsockopt(s,SOL_SOCKET,SO_REUSEADDR,(char *)val,sizeof(val); 有问题请继续追问。
不可以同时两个程序监听，你的B程序有错误，只是简单的修改了A程序的内容就拿来监听，其实还是A程序在监听，你要改A程序的监听目标，不能都是2185端口。
你说“将服务器IP改为127.0.0.1就出错了”。你试试把127.0.0.1改为电脑实际设置的IP试试。如192.168.1.20这样的，当然你事先要设置好本机IP
服务器端用127.0.0.1 客户端用你的ip地址
安装虚拟机

通常会采用修改注册表的方式改进Windows的系统参数。下面将为大家介绍Windows系统下的TCP参数优化方式，适用于Windows 2003、Windows XP、Windows 7以及Server版。对于具体的系统环境与性能需求，优化方式会有所差异，效果也不尽相同，仅是个人的建议。所有的优化操作都通过修改注册表实现，需要使用regedit命令进入注册表并创建或修改参数，修改完成后需要重启系统，以使之生效。以下使用的参数值均为10进制。1. TCPWindowSizeTCPWindowSize的值表示TCP的窗口大小。TCP Receive Window（TCP数据接收缓冲）定义了发送端在没有获得接收端的确认信息的状态下可以发送的最大字节数。此数值越大，返回的确认信息就越少，相应的在发送端和接收端之间的通信就越好。此数值较小时可以降低发送端在等待接收端返回确认信息时发生超时的可能性，但这将增加网络流量，降低有效吞吐率。TCP在发送端和接收端之间动态调整一个最大段长度MSS（Maximum Segment Size）的整数倍。MSS在连接开始建立时确定，由于TCP Receive Window被调整为MSS的整数倍，在数据传输中完全长度的TCP数据段的比例增加，故而提高了网络吞吐率。缺省情况下，TCP将试图根据MSS来优化窗口大小，起始值为16KB，最大值为64KB。TCPWindowSize的最大值通常为65535字节（64KB），以太网最大段长度为1460字节，低于64KB的1460的最大整数倍为62420字节，因而可以在注册表中将TCPWindowSize设置为62420，作为高带宽网络中适用的性能优化值。具体操作如下：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TCPWindowSize的REG_DWORD值，该值的范围是从0到65535，将该值设置为62420。2. TCP1323Opts为了更高效地利用高带宽网络，可以使用比上述TCP窗口大得多的TCP窗口大小，此特性是Windows 2000和Windows Server 2003中的新特性，称为TCP Window Scaling，它将以前的65535字节（64KB）的限制提高到了1073741824字节（1GB）。在带宽与延迟的乘积值很高的连接上（例如卫星连接），可能需要将窗口的大小增加到64KB以上。使用TCP Window Scaling，系统可以允许确认信息间更大数据量的传输，增加了网络吞吐量及性能。发送端和接收端往返通信所需的时间被称为回环时间（RTT）。TCP Window Scaling仅在TCP连接的双方都开启时才真正有效。TCP有一个时间戳选项，通过更加频繁地计算来提高RTT值的估测值，此选项特别有助于估测更长距离的广域网上连接的RTT值，并更加精确地调整TCP重发超时时间。时间戳在TCP报头提供了两个区域，一个记录开始重发的时间，另一个记录接收到的时间。时间戳对于TCP Window Scaling，即确认信息收到前的大数据包传送特别有用，激活时间戳仅仅在每个数据包的头部增加12字节，对网络流量的影响微乎其微。数据完整性与数据吞吐率最大化哪个更为重要是个需要评估的问题。在某些环境中，例如视频流传输，需要更大的TCP窗口，这是最重要的，而数据完整性排在第二位。在这种环境中，TCP Window Scaling可以不打开时间戳。当发送端和接收端均激活TCP Window Scaling和时间戳时，此特性才有效。不过，若在发包时加入了时间戳，经过NAT之后，如果前面相同的端口被使用过，且时间戳大于这个连接发出的SYN中的时间戳，就会导致服务器忽略该SYN，表现为用户无法正常完成TCP的3次握手。初始时生成小的TCP窗口，之后窗口大小将按照内部算法增大。具体操作如下：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TCP1323Opts的REG_DWORD值，该值的具体含义为：0（缺省值）表示禁用TCP Window Scaling和时间戳；1表示只启用TCP Window Scaling；2表示只启用时间戳；3表示同时启用TCP Window Scaling和时间戳。TCP1323Opts设置为激活TCP Window Scaling后，可以将上文中的注册表项TCPWindowSize的值增大，最大能达到1GB，为了达到最佳性能，这里的值最好设置成MSS的倍数，推荐值为256960字节。3. TCP 控制块表对于每个TCP连接，控制变量保存在一个称为TCP控制块（TCB）的内存块中。TCB表的大小由注册表项MaxHashTableSize控制。在活动连接很多的系统中，设定一个较大的表可以降低系统定位TCB表的时间。在TCB表上分区可以降低对表的访问的争夺。增加分区的数量，TCP的性能会得到优化，特别是在多处理器的系统上。注册表项NumTcbTablePartitions控制分区的数量，默认是处理器个数的平方。TCB通常预置在内存中，以防止TCP反复连接和断开时，TCB反复重新定位浪费时间，这种缓冲的方式促进了内存管理，但同时也限制了同一时刻允许的TCP连接数量。注册表项MaxFreeTcbs决定了处于空闲等待状态的TCB重新可用之前的连接数量，在NT架构中常设置成高于默认值，以确保有足够的预置的TCB。从Windows 2000开始添加了一个新特性，降低超出预置TCB运行的可能性。如果处于等待状态的连接多于MaxFreeTWTcbs中的设置，所有等待时间超过60秒的连接将被强制关闭，以后再次启用。此特性合并到Windows 2000 Server和Windows Server 2003后，MaxFreeTcbs将不再用于优化性能。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为MaxHashTableSize的REG_DWORD值，该值的范围是从1到65536，并且必须为2的N次方，缺省值为512，建议设为8192。然后在Parameters子键下创建或修改名为NumTcbTablePartitions的REG_DWORD值，该值的范围是从1到65536，并且必须为2的N次方，缺省值为处理器个数的平方，建议设为处理器核心数的4倍。4. TcpTimedWaitDelayTcpTimedWaitDelay的值表示系统释放已关闭的TCP连接并复用其资源之前，必须等待的时间。这段时间间隔就是以前的Blog中提到的TIME_WAIT状态（2MSL，数据包最长生命周期的两倍状态）。如果系统显示大量连接处于TIME_WAIT状态，则会导致并发量与吞吐量的严重下降，通过减小该项的值，系统可以更快地释放已关闭的连接，从而为新连接提供更多的资源，特别是对于高并发短连接的Server具有积极的意义。该项的缺省值是240，即等待4分钟后释放资源；系统支持的最小值为30，即等待时间为30秒。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TcpTimedWaitDelay的REG_DWORD值，该值的范围是从0到300，建议将该值设置为30。5. MaxUserPortMaxUserPort的值表示当应用程序向系统请求可用的端口时，TCP/IP可分配的最大端口号。如果系统显示建立连接时出现异常，那么有可能是由于匿名（临时）端口数不够导致的，特别是当系统打开大量端口来与Web service、数据库或其他远程资源建立连接时。该项的缺省值是十进制的5000，这也是系统允许的最小值。Windows默认为匿名（临时）端口保留的端口号范围是从1024到5000。为了获得更高的并发量，建议将该值至少设为32768以上，甚至设为理论最大值65534，特别是对于模拟高并发测试环境的Client具有积极的意义。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为MaxUserPort的REG_DWORD值，该值的范围是从5000到65534，缺省值为5000，建议将该值设置为65534。6. 动态储备动态储备的值使系统能自动调整其配置，以接受大量突发的连接请求。如果同时接收到大量连接请求，超出了系统的处理能力，那么动态储备就会自动增大系统支持的暂挂连接的数量（即Client已请求而Server尚未处理的等待连接数，TCP连接的总数包括已连接数与等待连接数），从而可减少连接失败的数量。系统的处理能力和支持的暂挂连接的数量不足时，Client的连接请求将直接被拒绝。缺省情况下，Windows 不启用动态储备，可以通过以下操作进行开启和设置：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesAFDParameters注册表子键，在Parameters子键下创建或修改下列名称的REG_DWORD值。EnableDynamicBacklog，值为1，表示开启动态储备。MinimumDynamicBacklog，值为128，表示支持的最小暂挂连接的数量为128。MaximumDynamicBacklog，值为2048，表示支持的最大暂挂连接的数量为2048。对于高并发短连接的Server，建议最大值设为1024及以上。DynamicBacklogGrowthDelta，值为128，表示支持的暂挂连接的数量的增量为128，即数量不足时自增长128，直到达到设定的最大值，如2048。7. KeepAliveTimeKeepAliveTime的值控制系统尝试验证空闲连接是否仍然完好的频率。如果该连接在一段时间内没有活动，那么系统会发送保持连接的信号，如果网络正常并且接收方是活动的，它就会响应。如果需要对丢失接收方的情况敏感，也就是说需要更快地发现是否丢失了接收方，请考虑减小该值。而如果长期不活动的空闲连接的出现次数较多，但丢失接收方的情况出现较少，那么可能需要增大该值以减少开销。缺省情况下，如果空闲连接在7200000毫秒（2小时）内没有活动，系统就会发送保持连接的消息。 通常建议把该值设为1800000毫秒，从而丢失的连接会在30分钟内被检测到。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为KeepAliveTime的REG_DWORD值，为该值设置适当的毫秒数。8. KeepAliveIntervalKeepAliveInterval的值表示未收到另一方对“保持连接”信号的响应时，系统重复发送“保持连接”信号的频率。在无任何响应的情况下，连续发送“保持连接”信号的次数超过TcpMaxDataRetransmissions（下文将介绍）的值时，将放弃该连接。如果网络环境较差，允许较长的响应时间，则考虑增大该值以减少开销；如果需要尽快验证是否已丢失接收方，则考虑减小该值或TcpMaxDataRetransmissions值。缺省情况下，在未收到响应而重新发送“保持连接”的信号之前，系统会等待1000毫秒（1秒），可以根据具体需求修改，具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为KeepAliveInterval的REG_DWORD值，为该值设置适当的毫秒数。9. TcpMaxDataRetransmissionsTcpMaxDataRetransmissions的值表示TCP数据重发，系统在现有连接上对无应答的数据段进行重发的次数。如果网络环境很差，可能需要提高该值以保持有效的通信，确保接收方收到数据；如果网络环境很好，或者通常是由于丢失接收方而导致数据的丢失，那么可以减小该值以减少验证接收方是否丢失所花费的时间和开销。缺省情况下，系统会重新发送未返回应答的数据段5次，可以根据具体需求修改，具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TcpMaxDataRetransmissions的REG_DWORD值，该值的范围是从0到4294967295，缺省值为5，根据实际情况进行设置。10. TcpMaxConnectRetransmisstionsTcpMaxConnectRetransmisstions的值表示TCP连接重发，TCP退出前重发非确认连接请求（SYN）的次数。对于每次尝试，重发超时是成功重发的两倍。在Windows Server 2003中默认超时次数是2，默认超时时间为3秒（在注册表项TCPInitialRTT中）。速度较慢的WAN连接中超时时间可相应增加，不同环境中可能会有不同的最优化设置，需要在实际环境中测试确定。超时时间不要设置太大否则将不会发生网络连接超时时间。具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParameters注册表子键，在Parameters子键下创建或修改名为TcpMaxConnectRetransmisstions的REG_DWORD值，该值的范围是从0到255，缺省值为2，根据实际情况进行设置。然后在Parameters子键下创建或修改名为TCPInitialRTT的REG_DWORD值，同样根据实际情况进行设置。11. TcpAckFrequencyTcpAckFrequency的值表示系统发送应答消息的频率。如果值为2，那么系统将在接收到2个分段之后发送应答，或是在接收到1个分段但在200毫秒内没有接收到任何其他分段的情况下发送应答；如果值为3，那么系统将在接收到3个分段之后发送应答，或是在接收到1个或2个分段但在200毫秒内没有接收到任何其他分段的情况下发送应答，以此类推。如果要通过消除应答延迟来缩短响应时间，那么建议将该值设为1。在此情况下，系统会立即发送对每个分段的应答；如果连接主要用于传输大量数据，而200毫秒的延迟并不重要，那么可以减小该值以降低应答的开销。缺省情况下，系统将该值设为2，即每隔一个分段应答一次。该值的有效范围是0到255，其中0表示使用缺省值2，可以根据具体需求修改，具体操作：浏览至HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTCPIPParametersInterfacesxx（xx由网络适配器决定）注册表子键，在xx子键下创建或修改名为TcpAckFrequency的REG_DWORD值，该值的范围是从1到13，缺省值为2，根据希望每发送几个分段返回一个应答而设置该值，建议百兆网络设为5，千兆网络设为13。https://www.cnblogs.com/larry-luo/p/11064346.html

整理自 CSDN 公众号1. 客户端TCP 三次握手的开始是客户端发起 SYN，如果服务端没有及时回复，那么会重传，重传的间隔和次数是可控的，默认是五次，第一次间隔 1 秒，第二次 2 秒，第三次 4 秒，第四次 8 秒，第五次16 秒，最终超时时间是 63 秒，因此在优化时可以修改重传次数和间隔，以尽快把错误暴露给应用程序。2. 服务端的半连接队列优化服务端在第一次返回 SYN + ACK 时，就会把这次请求维护进一个半连接队列，这个队列用来维护尚未完成的握手信息（相对于全连接），如果这个队列溢出了，服务端就无法继续接受新的请求了，这也是 SYN Flood 攻击的点。通过一个命令 netstat -s 可以得到累计的、由于半连接队列已满引发的失败次数，隔几秒执行一次就可以知道这个次数是否有上升的趋势以及分析是否正常。这种 SYN Flood 攻击之所以成立，是因为维护这个半连接队列一定要分配一定的内存资源，那么应对的方式之一 syncookies 就是如何不分配资源的前提下，可以确认是一次有效的连接并 establish。syncookies 的工作原理是，服务器使用一种算法，计算出一个哈希值，它包含了客户端发来请求的部分信息，再将这个哈希值和 SYN+ACK 一起返回给客户端，客户端也经过一些运算，再返回给服务端，那么服务端根据这个返回值和之前的计算值比较，如果合法，就可以建立有效连接，从而不会占据半连接队列的内存。应对 SYN 攻击时，只需将 syncookies 的参数值调为 1（半连接队列溢出时启用），即可。相当的，可以增大半连接队列，但是要和 accept 的队列同时增大才有效，（否则会导致 accept 队列溢出同样丢失 TCP 连接）此时，对于客户端来说已经是 established 状态，但是还要再返回给服务端一个 ACK，服务端收到后，服务端才是 established 状态并开始传数据，如果网络不稳定，同样的，服务端会重发 SYN+ACK，当网络不稳定时，应该增加服务端重发 SYN+ACK 的次数。3. 服务端的 accept 队列优化当连接已经建立、应用程序尚未调用时，TCP 连接会被保存在一个 accept 队列中，如果进程未能及时调用，就会导致 accept 队列溢出，溢出部分连接将被默认丢弃。对此可以做的是，选择向客户端发送 RST 报文，告知关闭这个连接，丢弃握手过程。打开这一功能需要将 tcp_abort_on_overflow 参数设置为 1。如果想让客户端了解是由于 accept 队列溢出造成连接失败可以这样做。当 tcp_abort_on_overflow 参数设置为 0 时，则如果 accept 队列溢出，就会丢弃客户端传来的 ACK（用于最后一次握手）。应对高并发流量时，更好的选择是 tcp_abort_on_overflow 参数设置为 0，这样对于客户端它的状态仍然是 established，客户端会定时发送带有 ack 报文的发送数据请求，一旦服务端的 accept 队列有空位，那么连接仍有可能建立成功。所以只有很确定在一段时间内 accept 都是将溢出的状态，才推荐 tcp_abort_on_overflow 参数设置为 1。同样的，可以调整 accept 队列长度，也可以查看累计的由于溢出导致丢失的连接总数，来判断趋势。在 Linux 3.7 内核版本之后，提供了 TCP Fast Open 功能，这个功能如此生效：初次建立 TCP 连接时，客户端在第一个 SYN 包中传入一个请求 cookie，表明打开 fast open 功能，服务端对应生成一个 cookie 给客户端，除此之外，三次握手没有不同，但是，在 cookie 没有过期之前，下一次再连接的时候，客户端发送带有 cookie 的 SYN 包，服务端校验了 cookie 有效以后，就可以开始传输数据了，从而节约了一个往返的时间消耗。TCP Fast Open 功能需要服务端和客户端同时打开才能生效。（备注一个之前看到差点忘了的知识点。当主动方收到被动方的 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。1. 主动方的优化关闭的方式有两种 RST 和 FIN，RST 是暴力关闭连接的方式，安全关闭连接则必须四次挥手。FIN 报文关闭则可以使用 close 和 shutdown 两种函数来实现。close 相对来说是“不优雅”的，调用 close 的一方的连接叫做「孤儿连接」，会同时关闭读和写，而 shutdown 可以控制是读还是写。关闭读的时候，会丢弃接收缓冲区里的所有数据，如果后续再接受到数据，也会悄悄丢弃，并发送 ACK，对方不会知道被丢弃了。关闭写的时候，会把发送缓冲区的数据全部发送并发送 FIN。（1）FIN_WAIT1 的优化主动方发送 FIN 以后，进入 FIN_WAIT1 状态，如果迟迟没收到 ACK，会定时重发 FIN，重发次数由 tcp_orphan_retries 参数控制，默认为 8 次，如果处于 FIN_WAIT1 状态的连接过多，应该考虑降低次数，重发次数超过参数时，连接会被直接关闭。如果遇到恶意攻击，可能无法发送出 FIN，因为 TCP 按顺序发送所有包， FIN 也不能绕过，另外如果对方的接收窗口已经满了，发送方也无法再发送数据。此时应该做的是调整 tcp_max_orphans 参数，它定义了「孤儿连接」的最大数量，当系统中的孤儿连接超过参数值，新增的孤儿连接不会再处于 FIN_WAIT1 状态，而是会被 RST 报文直接关闭。（只会影响 CLOSE 函数关闭的连接，不会影响 shutdown 关闭的，不会影响还有读或写的可能）（2）FIN_WAIT2 的优化主动方收到 ACK 后，会处于 FIN_WAIT2，因为被动方还可能有数据发送，如果是 shutdown 关闭，那它也可能还会发送数据，但是对于 close 关闭的连接，无法再发送和接收数据，保持在 FIN_WAIT2 的状态已经没有太大意义，tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。这个时间和 TIME_WAIT 状态时长是一致的。（3）TIME_WAIT 的优化TIME_WAIT 和 FIN_WAIT2 的时间是一致的，都是 2MSL，1MSL 表示一个报文在网络中存活的最长时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间），那么为什么是等待 2MSL 呢，其实就是允许报文至少丢失一次、再发送一次，这样第一个丢失了，等待的时间里第二个 ACK 还会到达，为什么不是 4MSL 以上呢，这是一个概率的问题，如果一个网络丢包率达到 1%，那么连续两次丢包的概率是万分之一，不必为了这种概率增加等待的时长。TIME_WAIT 有存在的意义，但是太多保持在这种状态的连接会占用双方资源，占据客户端的端口资源和服务端的系统资源。Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭。这个参数的设定应该取一个平衡点，即既不会太少导致高并发时产生连接间数据错乱的问题，也不会太多而导致耗尽端口和线程资源。对于用户端来讲，还可以启用 tcp_tw_reuse 参数来复用处于 TIME_WAIT 状态的连接（来节约接口资源。）这个参数有几个前提，一个是只有客户端可以打开，一个是 TIME_WAIT 状态也要保持 1 秒，另一个是要同步打开时间戳功能，报文带上时间戳就可以避免没有了 2MSL 时长以后的混乱情况，时间戳过期的报文就会被丢掉。另外对于 TIME_WAIT，还可以调整 socket 选项，来达到调用 close 关闭连接时跳过四次挥手直接关闭的效果，但不推荐。2. 被动方的优化首先，被动方收到 FIN 时，会自动回复 ACK，接着等待应用程序调用 close/shutdown 来结束连接，再发送 FIN。如果系统中同时查看到多个连接处于 CLOSE_WAIT 状态，则需要排查是否是应用程序出了故障。然后，当被动方也发送了 FIN 以后，还需要等待主动方回复一个 ACK，如果迟迟没收到，也会重发 FIN，重发次数也是 tcp_orphan_retries 参数控制，这点和主动方的优化一致，可以调整次数。（需确认被动方是否有 tcp_max_orphans 参数）3. 如果双方同时关闭？1.ACK 延迟目前在 TCP 中每传输一个报文都要求接收方进行确认，大量短而频繁的确认报文给网络带来了很多开销。因此采取了延迟 ACK 策略来减少 ACK 的数量，就是接收方收到一个报文以后，不会立即发送 ACK，而是等待 1~200ms，这期间若有回送数据报文就捎带确认，但收到两个连续数据报文或者等待超时则发送一个独立确认。有效减少了 ACK 的数量，改善了 TCP 的整体性能。2. 滑动窗口接收方的接收缓冲区不是不变的，接收到新的会变小，应用程序取出后又会变大，因此接收方会把自己当前的接收窗口大小放在 TCP 头告知发送方，如果不考虑拥塞控制，发送方的窗口大小「约等于」接收方的窗口大小。对于这一点，可以把 tcp_window_scaling 配置设为 1（默认打开）来扩大 TCP 通告窗口至 1G 大小。要使用这一选项，需要主动方在 SYN 中先告知，被动方在 SYN 中再反馈。但是缓冲区并非越大越好，还要考虑网络吞吐的能力。如果缓冲区与网络传输能力匹配，那么缓冲区的利用率就达到了最大化。3. 调整缓冲区大小这里需要说一个概念，就是带宽时延积，它决定网络中飞行报文的大小，它的计算方式：（1）发送缓冲区的调整发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。接收缓冲区要复杂一些：上面三个数字单位都是字节，它们分别表示：（2）接收缓冲区的调整接收缓冲区可以根据系统空闲内存的大小来调节接收窗口：（3）内存的判断那么如何判断内存紧张或充分呢？上面三个数字单位不是字节，而是「页面大小」，1 页表示 4KB，它们分别表示：在实际的场景中，TCP 缓冲区最小值保持默认 4K 即可，来提高并发处理能力；最大值则尽可能靠近带宽时延积，来最大化网络效率。总结以上：为了提高并发能力、提高网络效率，我们要充分利用网络能力和自己的内存。网络这方面就是将缓冲区大小的极值尽可能靠近带宽时延积，而同时对缓冲区的自动调节需要结合内存来判断，这个 TCP 内存的判断是通过系统内存计算出来的几个值来划分的，在不同区间会对分配给缓冲区的内存大小进行调整。以上就是 TCP 在不同阶段的优化策略和思路，有关拥塞控制和流量控制之后再补一篇笔记。

1.采用面向连接的三次握手实现可靠对象传输。 2.使用数据窗口机制协商队列大小实现数据队列传输。3.通过序列化应答和必要时重发数据包，TCP 为应用程序提供了可靠的传输流和虚拟连接服务。下面是找到的长篇大论中比较好的文章：一、TCP协议1、TCP 通过以下方式提供可靠性：◆ 应用程序分割为TCP认为最合适发送的数据块。由TCP传递给IP的信息单位叫做报文段。◆ 当TCP发出一个报文段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能记时收到一个确认，它 就重发这个报文段。◆ 当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常延迟几分之一秒。◆ TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化如果收到报文段的检验和有差错，TCP将丢弃这个报文段和不确认收到这个报文段。◆ 既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能失序，因此TCP报文段的到达也可能失序。如果必要，TCP将对收到的数据进行排序，将收到的数据以正确的顺序交给应用层。◆ 既然IP数据报会发生重复，TCP连接端必须丢弃重复的数据。◆ TCP还能提供流量控制，TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。另外，TCP对字节流的内容不作任何解释。2、TCP首部：TCP数据被封装在一个IP数据报中，格式如下：IP首部20 TCP首部20 TCP首部TCP首部格式如下：16位源端口号 16位目的端口号32位序号32位确认序号4位首部长度 保留6位 URG ACK PSH RST SYN FIN 16位窗口大小16位检验和 16位紧急指针选项数据说明：（1）每个TCP段都包括源端和目的端的端口号，用于寻找发送端和接收端的应用进程。这两个值加上IP首部的源端IP地址和目的端IP地址唯一确定一个TCP连接。（2）序号用来标识从TCP发送端向接收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。（3）当建立一个新连接时，SYN标志变1。序号字段包含由这个主机选择的该连接的初始序号ISN，该主机要发送数据的第一个字节的序号为这个ISN加1，因为SYN标志使用了一个序号。（4）既然每个被传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当时上次已成功收到数据字节序号加1。只有ACK标志为1时确认序号字段才有效。（5）发送ACK无需任何代价，因为32位的确认序号字段和ACK标志一样，总是TCP首部的一部分。因此一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。（6）TCP为应用层提供全双工的服务。因此，连接的每一端必须保持每个方向上的传输数据序号。（7）TCP可以表述为一个没有选择确认或否认的华东窗口协议。因此TCP首部中的确认序号表示发送方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。（8）首部长度需要设置，因为任选字段的长度是可变的。TCP首部最多60个字节。（9）6个标志位中的多个可同时设置为1◆ URG－紧急指针有效◆ ACK－确认序号有效◆ PSH－接收方应尽快将这个报文段交给应用层◆ RST－重建连接◆ SYN－同步序号用来发起一个连接◆ FIN－发送端完成发送任务（10）TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端期望接收的字节数。窗口大小是一个16为的字段，因而窗口大小最大为65535字节。（11）检验和覆盖整个TCP报文端：TCP首部和TCP数据。这是一个强制性的字段，一定是由发送端计算和存储，并由接收端进行验证。TCP检验和的计算和UDP首部检验和的计算一样，也使用伪首部。（12）紧急指针是一个正的偏移量，黄蓉序号字段中的值相加表示紧急数据最后一个字节的序号。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。（13）最常见的可选字段是最长报文大小MMS，每个连接方通常都在通信的第一个报文段中指明这个选项。它指明本端所能接收的最大长度的报文段。二、TCP连接的建立和终止1、建立连接协议（1） 请求端发送一个SYN段指明客户打算连接的服务器的端口，隐疾初始序号(ISN)，这个SYN报文段为报文段1。（2） 服务器端发回包含服务器的初始序号的SYN报文段（报文段2）作为应答。同时将确认序号设置为客户的ISN加1以对客户的SYN报文段进行确认。一个SYN将占用一个序号。（3） 客户必须将确认序号设置为服务器的ISN加1以对服务器的SYN报文段进行确认（报文段3）。这3个报文段完成连接的建立，称为三次握手。发送第一个SYN的一端将执行主动打开，接收这个SYN并发回下一个SYN的另一端执行被动打开。2、连接终止协议由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。（4） 客户段发回确认，并将确认序号设置为收到序号加1（报文段7）。3、连接建立的超时如果与服务器无法建立连接，客户端就会三次向服务器发送连接请求。在规定的时间内服务器未应答，则连接失败。4、最大报文段长度MSS最大报文段长度表示TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的MSS。一般，如果没有分段发生，MSS还是越大越好。报文段越大允许每个报文段传送的数据越多，相对IP和TCP首部有更高的网络利用率。当TCP发送一个 SYN时，它能将MSS值设置为外出接口的MTU长度减去IP首部和TCP首部长度。对于以太网，MSS值可达1460。如果目的地址为非本地的，MSS值通常默认为536，是否本地主要通过网络号区分。MSS让主机限制另一端发送数据报的长度，加上主机也能控制它发送数据报的长度，这将使以较小MTU连接到一个网络上的主机避免分段。5、 TCP的半关闭TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力，这就是TCP的半关闭。客户端发送FIN，另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后，才发送FIN关闭这个方向的连接，客户端再对这个FIN确认，这个连接才彻底关闭。6、2MSL连接TIME_WAIT状态也称为2MSL等待状态。每个TCP必须选择一个报文段最大生存时间（MSL）。它是任何报文段被丢弃前在网络的最长时间。处理原则：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT状态停留的时间为2MSL。这样可以让TCP再次发送最后的ACK以避免这个ACK丢失（另一端超时并重发最后的FIN）。这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间，定义这个连接的插口不能被使用。7、平静时间TCP在重启的MSL秒内不能建立任何连接，这就是平静时间。8、FIN_WAIT_2状态在FIN_WAIT_2状态我们已经发出了FIN，并且另一端也对它进行了确认。只有另一端的进程完成了这个关闭，我们这端才会从 FIN_WAIT_2状态进入TIME_WAIT状态。这意味着我们这端可能永远保持这个状态，另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭。9、复位报文段TCP首部的RST位是用于复位的。一般，无论合适一个报文端发往相关的连接出现错误，TCP都会发出一个复位报文段。主要情况：（1）到不存在的端口的连接请求；（2）异常终止一个连接。10、同时打开为了处理同时打开，对于同时打开它仅建立一条连接而不是两条连接。两端几乎在同时发送SYN，并进入SYN_SENT状态。当每一端收到SYN时，状态变为SYN_RCVD，同时他们都再发SYN并对收到的SYN进行确认。当双方都收到SYN及相应的ACK时，状态都变为ESTABLISHED。一个同时打开的连接需要交换4个报文段，比正常的三次握手多了一次。11、 同时关闭当应用层发出关闭命令，两端均从ESTABLISHED变为FIN_WAIT_1。这将导致双方各发送一个FIN，两个FIN经过网络传送后分别到达另一端。收到FIN后，状态由FIN_WAIT_1变为CLOSING，并发送最后的ACK。当收到最后的ACK，状态变为TIME_WAIT。同时关闭和正常关闭的段减缓数目相同。12、TCP选项每个选项的开始是1字节的kind字段，说明选项的类型。Kind=1:选项表结束（1字节） Kind=1:无操作（1字节） Kind=2：最大报文段长度（4字节） Kind=3:窗口扩大因子（4字节） Kind=8:时间戳（10字节）三、TCP的超时和重传对于每个TCP连接，TCP管理4个不同的定时器。（1） 重传定时器用于当希望收到另一端的确认。（2） 坚持定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。（3） 保活定时器可检测到一个空闲连接的另一端何时崩溃或重启。（4） 2MSL定时器测量一个连接处于TIME_WAIT状态的时间。1、往返时间测量TCP超时和重传重最重要的就是对一个给定连接的往返时间（RTT）的测量。由于路由器和网络流量均会变化，因此TCP应该跟踪这些变化并相应地改变超时时间。首先TCP必须测量在发送一个带有特别序号地字节和接收到包含该字节地确认之间的RTT。2、拥塞避免算法该算法假定由于分组收到损坏引起的丢失是非常少的，因此分组丢失就意味着在源主机和目的主机之间的某处网络上发生了阻塞。有两种分组丢失的指示：发生超时和收到重复的确认。拥塞避免算法需要对每个连接维持两个变量：一个拥塞窗口cwnd和一个慢启动门限ssthresh。(1) 对一个给定的连接，初始化cwnd为1个报文段，ssthresh为65535个字节。(2) TCP输出例程的输出不能超过cwnd和接收方通告窗口的大小。拥塞避免是发送方使用的流量控制。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。(3) 当拥塞发生时，ssthresh被设置为当前窗口大小的一般(cwnd和接收方通告窗口大小的最小值，但最小为2个报文段)。此外，如果是超时引起了拥塞，则cwnd被设置为1个报文段。(4) 当新的数据被对方确认时，就增加cwnd，但增加的方法依赖与是否正在进行慢启动或拥塞避免。如果cwnd小于或等于ssthresh，则正在进行慢启动，否则正在进行拥塞避免。3、快速重传和快速恢复算法如果我们一连串收到3个或以上的重复ACK，就非常可能是一个报文段丢失了。于是我们就重传丢失的数据报文段，而无需等待超时定时器溢出。（1） 当收到第3个重复的ACK时，将ssthresh设置为当前拥塞窗口cwnd的一半，重传丢失的报文段，设置cwnd为ssthresh加上3倍的报文段大小。（2） 每次收到另一个重复的ACK时，cwnd增加1个报文段大小并发送一个1个分组，如果允许的话。（3）当下一个确认新数据的ACK到达时，设置cwnd为ssthresh，这个ACK应该时在进行重传后的一个往返时间内对步骤1重重传的确认。另外，这个 ACK也应该是对丢失的分组和收到的第一个重复的ACK之间的所有中间报文段的确认。4、 ICMP差错TCP如何处理一个给定的连接返回的ICMP差错。TCP能够遇到的最常见的ICMP差错就是源站抑制、主机不可达和网络不可达。（1） 一个接收到的源站抑制引起拥塞窗口cwnd被置为1个报文段大小来发起慢启动，但是慢启动门限ssthresh没有变化，所以窗口将打开直到它开放了所有的通路或者发生了拥塞。（2） 一个接收到的主机不可达或网络不可达实际都被忽略，因为这两个差错都被认为是短暂现象。TCP试图发送引起该差错的数据，尽管最终有可能会超时。5、重新分组：当TCP超时并重传时，它并不一定要重传同样的报文段，相反，TCP允许进行重新分组而发送一个较大的报文段。这是允许的，因为TCP是使用字节序号而不是报文段序号来进行识别它所要发送的数据和进行确认。四、TCP的坚持定时器ACK的传输并不可靠，也就是说，TCP不对ACK报文段进行确认，TCP只确认那些包含数据的ACK报文段。为了防止因为ACK报文段丢失而双方进行等待的问题，发送方用一个坚持定时器来周期性地向接收方查询。这些从发送方发出地报文段称为窗口探查。五、TCP的保活定时器如果一个给定的连接在2小时内没有任何动作，那么服务器就向客户发送一个探查报文段。客户主机必须处于以下4个状态之一。(1) 客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方的正常工作的。服务器在2小时内将保活定时器复位。(2) 客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务器将不能收到对探查的响应，并在75秒后超时。总共发送10个探查，间隔75秒。(3) 客户主机崩溃并已经重新启动。这是服务器将收到一个对其保活探查的响应，但这个响应是一个复位，使得服务器终止这个连接。(4) 客户主机正常运行，但是从服务器不可达。六、TCP的一些性能1、 路径MTU发现：TCP的路径MTU发现按如下方式进行：在连接建立时，TCP使用输出接口或对段声明的MSS中的最下MTU作为其实的报文段大小。路径MTU发现不允许TCP超过对端声明的MSS。如果对端没有指定一个MSS，则默认为536。一旦选定了起始的报文段大小，在该连接上的所有被TCP发送的IP数据报都将被设置DF位。如果中间路由器需要对一个设置了DF标志的数据报进行分片，它就丢弃这个数据报，并产生一个ICMP的“不能分片”差错。如果收到这个ICMP差错，TCP就减少段大小并进行重传。如果路由器产生的是一个较新的该类ICMP差错，则报文段大小被设置位下一跳的MTU减去 IP和TCP的首部长度。如果是一个较旧的该类ICMP差错，则必须尝试下一个可能的最小MTU。2、 长肥管道一个连接的容量＝带宽X时延（RTT）。具有大的带宽时延乘积的网络称为长肥网络（LFN）。一个运行在LFN的TCP连接称为长肥管道。管道可以被水平拉长（一个长的RTT）,或被垂直拉高（较高的带宽），或两个方向拉伸。3、窗口扩大选项：窗口扩大选项使TCP的窗口定义从16位增加到32位，这并不是通过修改TCP首部来实现的，TCP首部仍然使用16位，而是通过定义一个选项实现对16位的扩大操作来完成的。4、时间戳选项：时间戳选项使发送方在每个报文段中放置一个时间戳值。接收方在确认中返回这个数值，从而允许发送方为每一个收到的ACK计算RTT。参考资料：http://tb.blog.csdn.net/TrackBack.aspx?PostId=1404888