tcp连接爆发(假定tcp在开始建立连接时)

TCP/IP协议是什么TCP和UDP处在同一层---运输层，但是TCP和UDP最不同的地方是，TCP提供了一种可靠的数据传输服务，TCP是面向连接的，也就是说，利用TCP通信的两台主机首先要经历一个“拨打电话”的过程，等到通信准备结束才开始传输数据，最后结束通话。所以TCP要比UDP可靠的多，UDP是把数据直接发出去，而不管对方是不是在收信，就算是UDP无法送达，也不会产生ICMP差错报文，这一经时重申了很多遍了。把TCP保证可靠性的简单工作原理:应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的 数据报长度将保持不变。由TCP传递给IP的信息单位称为报文段或段当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能 及时收到一个确认，将重发这个报文段.当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒.TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输 过程中的任何变化。如果收到段的检验和有差错， T P将丢弃这个报文段和不确认收到此报文段(希望发端超时并重发)。既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段 的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。从这段话中可以看到，TCP中保持可靠性的方式就是超时重发，这是有道理的，虽然TCP也可以用各种各样的ICMP报文来处理这些，但是这也不是可靠的，最可靠的方式就是只要不得到确认，就重新发送数据报，直到得到对方的确认为止。TCP的首部和UDP首部一样，都有发送端口号和接收端口号。但是显然，TCP的首部信息要比UDP的多，可以看到，TCP协议提供了发送和确认所需要的所有必要的信息。可以想象一个TCP数据的发送应该是如下的一个过程。双方建立连接发送方给接受方TCP数据报，然后等待对方的确认TCP数据报，如果没有，就重新发，如果有，就发送下一个数据报。接受方等待发送方的数据报，如果得到数据报并检验无误，就发送ACK(确认)数据报，并等待下一个TCP数据报的到来。直到接收到FIN(发送完成数据报)中止连接可以想见，为了建立一个TCP连接，系统可能会建立一个新的进程(最差也是一个线程)，来进行数据的传送--TCP协议TCP是一个面向连接的协议，在发送输送之前 ，双方需要确定连接。而且，发送的数据可以进行TCP层的分片处理。TCP连接的建立过程 ，可以看成是三次握手 。而连接的中断可以看成四次握手 。1.连接的建立在建立连接的时候，客户端首先向服务器申请打开某一个端口(用SYN段等于1的TCP报文)，然后服务器端发回一个ACK报文通知客户端请求报文收到，客户端收到确认报文以后再次发出确认报文确认刚才服务器端发出的确认报文(绕口么)，至此，连接的建立完成。这就叫做三次握手。如果打算让双方都做好准备的话，一定要发送三次报文，而且只需要三次报文就可以了。可以想见，如果再加上TCP的超时重传机制，那么TCP就完全可以保证一个数据包被送到目的地。2.结束连接TCP有一个特别的概念叫做half-close，这个概念是说，TCP的连接是全双工(可以同时发送和接收)连接，因此在关闭连接的`时候，必须关闭传和送两个方向上的连接。客户机给服务器一个FIN为1的TCP报文，然后服务器返回给客户端一个确认ACK报文，并且发送一个FIN报文，当客户机回复ACK报文后(四次握手)，连接就结束了。3.最大报文长度在建立连接的时候，通信的双方要互相确认对方的最大报文长度(MSS)，以便通信。一般这个SYN长度是MTU减去固定IP首部和TCP首部长度。对于一个以太网，一般可以达到1460字节。当然如果对于非本地的IP，这个MSS可能就只有536字节，而且，如果中间的传输网络的MSS更加的小的话，这个值还会变得更小。4.客户端应用程序的状态迁移图客户端的状态可以用如下的流程来表示：CLOSED->SYN_SENT->ESTABLISHED->FIN_WAIT_1->FIN_WAIT_2->TIME_WAIT->CLOSED以上流程是在程序正常的情况下应该有的流程，从书中的图中可以看到，在建立连接时，当客户端收到SYN报文的ACK以后，客户端就打开了数据交互地连接。而结束连接则通常是客户端主动结束的，客户端结束应用程序以后，需要经历FIN_WAIT_1，FIN_WAIT_2等状态，这些状态的迁移就是前面提到的结束连接的四次握手。5.服务器的状态迁移图服务器的状态可以用如下的流程来表示：CLOSED->LISTEN->SYN收到->ESTABLISHED->CLOSE_WAIT->LAST_ACK->CLOSED在建立连接的时候，服务器端是在第三次握手之后才进入数据交互状态，而关闭连接则是在关闭连接的第二次握手以后(注意不是第四次)。而关闭以后还要等待客户端给出最后的ACK包才能进入初始的状态。6.TCP服务器设计前面曾经讲述过UDP的服务器设计，可以发现UDP的服务器完全不需要所谓的并发机制，它只要建立一个数据输入队列就可以。但是TCP不同，TCP服务器对于每一个连接都需要建立一个独立的进程(或者是轻量级的，线程)，来保证对话的独立性。所以TCP服务器是并发的。而且TCP还需要配备一个呼入连接请求队列(UDP服务器也同样不需要)，来为每一个连接请求建立对话进程，这也就是为什么各种TCP服务器都有一个最大连接数的原因。而根据源主机的IP和端口号码，服务器可以很轻松的区别出不同的会话，来进行数据的分发。TCP的交互数据流对于交互性要求比较高的应用，TCP给出两个策略来提高发送效率和减低网络负担：(1)捎带ACK。(2)Nagle算法(一次尽量多的发数据)捎带ACK的发送方式这个策略是说，当主机收到远程主机的TCP数据报之后，通常不马上发送ACK数据报，而是等上一个短暂的时间，如果这段时间里面主机还有发送到远程主机的TCP数据报，那么就把这个ACK数据报“捎带”着发送出去，把本来两个TCP数据报整合成一个发送。一般的，这个时间是200ms。可以明显地看到这个策略可以把TCP数据报的利用率提高很多。Nagle算法上过bbs的人应该都会有感受，就是在网络慢的时候发贴，有时键入一串字符串以后，经过一段时间，客户端“发疯”一样突然回显出很多内容，就好像数据一下子传过来了一样，这就是Nagle算法的作用。Nagle算法是说，当主机A给主机B发送了一个TCP数据报并进入等待主机B的ACK数据报的状态时，TCP的输出缓冲区里面只能有一个TCP数据报，并且，这个数据报不断地收集后来的数据，整合成一个大的数据报，等到B主机的ACK包一到，就把这些数据“一股脑”的发送出去。虽然这样的描述有些不准确，但还算形象和易于理解，我们同样可以体会到这个策略对于低减网络负担的好处。在编写插口程序的时候，可以通过TCP_NODELAY来关闭这个算法。并且，使用这个算法看情况的，比如基于TCP的X窗口协议，如果处理鼠标事件时还是用这个算法，那么“延迟”可就非常大了。 ;

1、可使用以下命令，查看当前服务器启动的httpd进程数，亦即当前服务器提供httpd服务的并发请求数。2、获取服务器实时的httpd服务并发请求数，可以与配置文件/etc/httpd/conf/httpd.conf中的MaxRequestWorkers 数量进行对比，看是否需要对最大服务并发数进行更改。3、运行以下命令，则可以对当前服务器为提供web服务，而开放80端口，与外部请求建立连接的连接数进行查看和统计。4、当前服务器的httpd服务已建立连接数，即httpd服务的TCP连接状态为ESTABLISH的连接，所以可以用以下命令查看、统计。5、通过查看当前httpd服务的TCP连接数，可对请求访问的IP进行分类汇总，查看是否存在同一IP地址恶意刷连接，过多占用系统资源情况存在，进而做出必要的处理。查看统计命令如下。6、如果某个IP地址的连接请求过多，我们则可以通过修改配置文件/etc/httpd/conf/httpd.conf，加入以下语句来阻止它的访问。
TCPIP并发连接数就是同时可以访问计算机的ip数量 。 1、一台电脑一个ip ，为了缓解服务器压力，XP默认限制为10 所以很多BT下载软件通过破解来连接更多的服务器2、因此现在很过下载软件如迅雷中为了提高下载速度就提供了破解程序在里面。3、具体连接数适不同情况而定，过大对机子有影响，太小速度慢，在用迅雷时迅雷会提示连接数，这是选择自动修改即可，这样是根据网速和机子本身而定的，比较稳定。4、更改为512或更高的数值 ，512差不多了下载速度超快，不可能的除非加钱给运营商把兆数加大，其实宽带就像水管一样给多大就多大的水，在怎么在水龙头上搞花头都怎么大，下载速度一样，运营商要保证那些大客户的利益如果有在电脑上就可以控制速度。 那不要光纤不要千兆百兆了。
如何修改TCP/IP并发连接数,网络上提供不少修改办法,但其中有不少是行通的,本文将做详细分析. 一、注册表修改法的误区为了突破SP2对TCP并发连接数的限制，网上曾经流传过一种修改注册表的方法，操作步骤如下：单击“开始”/运行，输入Regedit打开注册表，定位到HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters下，修改的“TcpNumConnections”的键值，将之由10改为150，即设置TCP最大并发连接数为150。经过实际测试，我们发现该方法看起来有效，但实质上并不能突破并发连接数限制，提高SP2的多线程访问速度。因为SP2对线程数目的控制，是通过“Tcpip.sys”这个系统文件来实现的，并不是通过注册表实现的，因此，该方法不能增加SP2的TCP并发连接数。二、使用工具来替换Tcpip．sys为了突破SP2的TCP并发连接数限制，正确地方法是修改Windows XP SP2的系统文件Tcpip.sys。Tcpip.sys是Windows XP SP2重要的系统文件，位于“C:Windowssystem32drivers目录下。该文件由于平时受到系统保护，所以正常情况下你是无法替换它的，必须在安全模式或纯DOS模式下才能替换，建议你使用以下专门工具、来替换“Tcpip.sys”文件，操作步骤如下：从网上http://www.lvllord.de/download.php?url=en/EvID4226Patch223d-en.zip下载替换工具(仅为30KB)，用它来修改系统文件Tcpip.sys最大安全并发连接限制；然后备份一下C:Windowssystem32driversTcpip.sys文件。接下来，双击打开下载文件ZIP压缩包，运行其中的替换工具EvID4226Patch.exe，随之将弹出一个命令行提示符窗口，首先显示Windows当前的Tcpip.sys文件版本，以及并发连接的限制数值(默认为10)；接着询问你是否将连接数限制在50，你可以选择“Yes/No/Change”，如果你输入“Y”，则会将并发连接数改为“50”，如果想改为其他数(例如150)，可以在提示符后输入“c”，然后输入最大的并发连接数(例如150)回车，最后在提示符下输入“Y”并回车，这样就替换了Tcpip.sys文件；Tcpip.sys文件被替换后，随之会弹出系统文件保护对话框，你可以点击“取消”按钮，然后点击“是”按钮，重新启动后，Tcpip.sys文件的替换就大功告成了！现在你的最大并发连接数已超过10个，达到了150个，因此Windows XP SP2的多线程访问速度得到了提升，当你用FlashGet、BT等多线程下载时，就不会感到网络带宽的限制了。三、DOS下修改Tcpip．sys文件以上替换程序EvID4226Patch.exe也可以在DOS下使用，方法是：首先把EvID4226Patch.exe拷贝到C盘根目录下；然后再进入DOS模式，进入C盘根目录，输入命令EvID4226Patch/L=$n$/w=C:WINDOWSsystem32drivers/L=tcpip.sys即可修改Tcpip.sys文件。注意：以上$n$为你要设置的最大安全连接数，假如要把最大并发连接数设置为150个线程，那么输入命令EvID4226Patch/L=150/w=C:WINDOWSsystem32drivers/L=tcpip.sys即可。四、使用比特精灵附带的工具比特精灵附带的工具“TCP/IP连接数破解补丁”也可以替换Tcpip.sys，突破SP2的TCP并发连接数限制。从网上http://download.pchome.net/php/dl.php?sid=15504下载比特精灵(BitSpirit)V2.7.2.225简体中文正式版，然后双击下载文件进行安装。你可以选择安装哪些组件(下图2)，应该安装“用于Windows XP SP2的TCP/IP连接数破解补丁”，安装结束后，XP开始菜单中就会有BitSpirit程序组，单击其中的“XP SP2连接数破解补丁”，即可修改Tcpip.sys文件。单击“XP SP2连接数破解补丁”，弹出该软件的界面，界面中列出了当前Tcpip.sys的版本、及最大并发连接数(右图3)，你可以在“TCP/IP Linitation”输入一个数，来设置最大并发连接数，例如输入150，然后按“Apply”按钮，重启系统后，你的SP2最大并发连接数就改为了150。 以上几种方法虽然提高了Windows XP SP2的多线程访问速度，但却降低了SP2的安全性能，如果你的电脑感染了病毒和木马，过多地启用新线程，会加速病毒和木马地蔓延，因此你在追求网络下载速度的同时，也要注意网络安全。建议你及时安装升级杀毒软件和防火墙，如果是普通用户，可以利用上面的方法，将TCP最大并发连接数设置为10～30，BT用户可以设置为100～150。
深度优化工具，雨林木风工具等，很多工具都可以修改的
用BT啊，迅雷一类下载软件都能，，，如果不想麻烦，用FlashGet，安装完第一次打开就会提示你是否修改连接数。

TCP/IP详解--接收RST回应的几种情况：1、端口未打开服务器程序端口未打开而客户端来连接。这种情况是最为常见和好理解的一种了。去telnet一个未打开的TCP的端口可能会出现这种错误。这个和操作系统的实现有关。在某些情况下，操作系统也会完全不理会这些发到未打开端口请求。2、请求超时曾经遇到过这样一个情况:一个客户端连接服务器，connect返回-1并且error=EINPROGRESS。 直接telnet发现网络连接没有问题。ping没有出现丢包。用抓包工具查看，客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。3、提前关闭关于TCP，我想我们在教科书里都读到过一句话，'TCP是一种可靠的连接'。 而这可靠有这样一种含义，那就是操作系统接收到的来自TCP连接中的每一个字节，我都会让应用程序接收到。扩展资料TCP/IP连接三次握手在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。第一次握手：建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认； SYN：同步序列编号(Synchronize Sequence Numbers)第二次握手：服务器收到syn包,必须确认客户的SYN（ack=j+1）,同时自己也发送一个SYN包（syn=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。完成三次握手，客户端与服务器开始传送数据。
1、首先，创建tcp服务器，创建的方式如下面图中所示，先创建一个net服务，然后监听connect和data事件，并对收到的数据进行确认，监听端口8431。2、创建tcp客户端，连接上面建立的tcp服务器，并发送 你好，并接收来自服务器的确认信息。3、下面显示的是服务器接收到的数据，并显示出来，然后向客户端发送数据确认。4、显示来自服务器的确认数据，这样一个tcp服务器和客户端就建立起来了。
仅从抓包信息看是服务器的一个流量控制机制启动了。服务器发回rst位，同时win置为0，是告诉客户端不要发包。按tcp流控机制来说，此时客户端应该停止发包，直至服务器发送信息告诉客户端可以继续发送。

TCP SYN Flood攻 击的原理机制/检测与防范及防御方法现在的攻击者,无所不在了.对于一些攻击手法,很多高 手也都是看在眼里而没什么实质性防范措施.除了改端 口,换IP,弄域名..还能做什么? 本篇文章介绍了TCP SYN Flood攻击的原理机制/检测与防范及防御方法,希望能给大伙一个思路. TCP SYN Flood攻击的机制客户端通过发送在TCP报头中SYN标志置位的数据分段到服务端来请求建立连接。通常情况下，服务端会按照IP报头中的来源地址来返回SYN/ACK置位 的数据包给客户端，客户端再返回ACK到服务端来完成一个完整的连接(Figure-1)。 在攻击发生时，客户端的来源IP地址是经过伪造的(spoofed)，现行的IP路由机制仅检查目的IP地址并进行转发，该IP包到达目的主机后返回 路径无法通过路由达到的，于是目的主机无法通过TCP三次握手建立连接。在此期间因为TCP缓存队列已经填满，而拒绝新的连接请求。目的主机一直尝试直至 超时(大约75秒)。这就是该攻击类型的基本机制。发动攻击的主机只要发送较少的，来源地址经过伪装而且无法通过路由达到的SYN连接请求至目标主机提供TCP服务的端口，将目的主机的TCP缓存队列 填满，就可以实施一次成功的攻击。实际情况下，发动攻击时往往是持续且高速的。 Figure-3 SYN Flood Attack 这里需要使用经过伪装且无法通过路由达到的来源IP地址，因为攻击者不希望有任何第三方主机可以收到来自目的系 统返回的SYN/ACK，第三方主机会返回一个RST(主机无法判断该如何处理连接情况时，会通过RST重置连接)，从而妨碍攻击进行。 Figure-4 IP Spoofing 由此可以看到，这种攻击方式利用了现有TCP/IP协议本身的薄弱环节，而且攻击者可以通过IP伪装有效的隐蔽自己。但对于目的主机来说，由于无法判 断攻击的真正来源。而不能采取有效的防御措施。TCP SYN Flood检测与防范 一、分析 从上面的分析，可以看出TCP SYN Flood远程拒绝服务攻击具有以下特点：针对TCP/IP协议的薄弱环节进行攻击； 发动攻击时，只要很少的数据流量就可以产生显著的效果；攻击来源无法定位； 在服务端无法区分TCP连接请求是否合法。二、系统检查 一般情况下，可以一些简单步骤进行检查，来判断系统是否正在遭受TCP SYN Flood攻击。1、服务端无法提供正常的TCP服务。连接请求被拒绝或超时； 2、通过 netstat -an 命 令检查系统，发现有大量的SYN_RECV连接状态。 三、防范 如何才能做到有效的防范呢?1、 TCP Wrapper 使用TCP Wrapper(只有unix-like系统支持该功能，NT?可怜)可能在某些有限的场合下有用，比如服务端只处理有限来源IP的TCP连接请求，其它 未指定来源的连接请求一概拒绝。这在一个需要面向公众提供服务的场合下是不适合的。而且攻击者可以通过IP伪装(IP Spoof)来直接攻击受TCP Wrapper保护的TCP服务，更甚者可以攻击者可以伪装成服 务器本身的地址进行攻击。 2、增加TCP Backlog容量 增加TCP Backlog容量是一种治标不治本的做法。它一方面要占用更多的系统内存，另一方面延长了TCP处理缓存队列的时间。攻击者只要不停地的进行SYN Flood一样可以达到拒绝服务的目的。3、 ISP接入 所有的ISP在边界处理进入的主干网 络的IP数据包时检测其来源地址是否合法，如果非指定来源IP地址范围，可以认为是IP Spoofing行为并将之丢弃。 在实际环境中，应为涉及的范围太过广泛，该方案无法实施。这是一个社会问题而非技 术问题。TCP SYN Flood检测与防范 一、TCP连接监控(TCP Interception) 为了有效的防范TCP SYN Flood攻击，在保证通过慢速网络的用户可以正常建立到服务端的合法连接的同时，需要尽可能的减少服务端TCP Backlog的清空时间，大多数防 火墙采用了TCP连接监控的工作模式。 1.防火墙接到来自用户端Z的SYN连接请求，在本地建立面向该连接的监控表项；2.防火墙将该连接请求之转发至服务端A； 3.服务端A相应该连接请求返回SYN/ACK，同时更新与该连接相关联的监控表项；4.防火墙将该SYN/ACK转发至用户端Z； 5.防火墙发送ACK至服务端A，同时服务端A中TCP Backlog该连接的表项被移出；6.这时，根据连接请求是否合法，可能有以下两种情况发生: a.如果来自用户端Z的连接请求合法，防火墙将该ACK转发至服务端A，服务端A会忽略该ACK，因为一个完整的TCP连接已经建立； b.如果来自用户端Z的连接请求非法(来源IP地址非法)，没有在规定的时间内收到返回的ACK，防火墙会发送RST至服务端A以拆除该连接。7.开始TCP传输过程。 由此可以看出，该方法具有两个局限: 1.不论是否合法的连接请求都直接转发至服务端A，待判断为非法连接(无返回ACK)时才采取措施拆除连接，浪费服务端系统资源； 2.防火墙在本地建立表项以监控连接(一个类似TCP Backlog的表)，有可能被攻击者利用。二、天网DoS防御网关 天网防火墙采用经过优化的TCP连接监控工作方式。该方式在处理TCP连接请求的时候，在确定连接请求是否合法以前，用户端Z与服务端A是隔断的。 1.防火墙接到来自用户端Z的SYN连接请求； 2.防火墙返回一个经过特殊处理的SYN/ACK至客户端Z以验证连接的合法性；3.这时，根据连接请求是否合法，可能有以下两种情况发生: a．防火墙接收到来自客户端Z的ACK回应，该连接请求合法。转至第4步继续；b．防火墙没有接收到来自客户端Z的ACK回应，该连接请求非法，不进行处理； 4.防火墙在本地建立面向该连接的监控表项，并发送与该连接请求相关联的SYN至服务端A； 5.防火墙接到来自服务端A的SYN/ACK回应；6.防火墙返回ACK以建立一个完整的TCP连接； 7.防火墙发送ACK至客户端Z，提示可以开始TCP传输过程。其中，在第2/3/4/7步过程中，防火墙内部进行了如下操作: 1.在第2步中，为了验证连接的合法性，防火墙返回的SYN/ACK是经过特殊处理的，并提示客户端Z暂时不要传送有效数据； 2.在第3步中，防火墙接收到来自客户端Z的ACK，检验其合法性。 3.在第4步中，防火墙在本地建立面向该连接的监控表项，同时发送与该连接相关的SYN至服务端A； 4.在第7步中，防火墙通过将TCP数据传输与监控表项进行比对，并调整序列号和窗口以使之匹配。开始TCP数据传输。 在这里，天网防火墙通过高效的算法（64K位的Hash）提供了超过30万以上的同时连接数的容量，为数据传输的高效和可靠提供了强有力地保障。 希望能帮到你，求采纳。
SYN Flood是当前最流行的DoS(拒绝服务攻击)与DDoS(分布式拒绝服务攻击)的方式之一，它是利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽(CPU满负荷或内存不足)的攻击方式，最终导致系统或服务器宕机。在讨论SYNFlood原理前，我们需要从TCP连接建立的过程开始说起：TCP与UDP不同，它是基于连接的，为了在服务端和客户端之间传送TCP数据，必须先建立一个虚拟电路，也就是TCP连接。也就是我们经常听说的TCP协议中的三次握手（Three-wayHandshake），建立TCP连接的标准过程如下：首先，客户端发送一个包含SYN标志的TCP报文，SYN即同步（Synchronize），同步报文会指明客户端使用的端口以及TCP连接的初始序号;其次，服务器在收到客户端的SYN报文后，将返回一个SYN+ACK（即确认Acknowledgement）的报文，表示客户端的请求被接受，同时TCP初始序号自动加一。最后，客户端也返回一个确认报文ACK给服务器端，同样TCP序列号被加一，到此一个TCP连接完成。SYNFlood攻击正是利用了TCP连接的三次握手，假设一个用户向服务器发送了SYN报文后突然死机或掉线，那么服务器在发出SYN+ACK应答报文后是无法收到客户端的ACK报文的(第三次握手无法完成)，这种情况下服务器端一般会重试(再次发送SYN+ACK给客户端)并等待一段时间后丢弃这个未完成的连接，这段时间的长度我们称为SYNTimeout，一般来说这个时间是分钟的数量级(大约为30秒-2分钟)；一个用户出现异常导致服务器的一个线程等待1分钟并不会对服务器端造成什么大的影响，但如果有大量的等待丢失的情况发生，服务器端将为了维护一个非常大的半连接请求而消耗非常多的资源。我们可以想象大量的保存并遍历也会消耗非常多的CPU时间和内存，再加上服务器端不断对列表中的IP进行SYN+ACK的重试，服务器的负载将会变得非常巨大。如果服务器的TCP/IP栈不够强大，最后的结果往往是堆栈溢出崩溃。相对于攻击数据流，正常的用户请求就显得十分渺小，服务器疲于处理攻击者伪造的TCP连接请求而无暇理睬客户的正常请求，此时从正常客户会表现为打开页面缓慢或服务器无响应，这种情况就是我们常说的服务器端SYNFlood攻击(SYN洪水攻击)。从防御角度来讲，存在几种的解决方法：第一种是缩短SYNTimeout时间，由于SYNFlood攻击的效果取决于服务器上保持的SYN半连接数，这个值=SYN攻击的频度xSYNTimeout，所以通过缩短从接收到SYN报文到确定这个报文无效并丢弃改连接的时间，例如设置为20秒以下，可以成倍的降低服务器的负荷。但过低的SYNTimeout设置可能会影响客户的正常访问。第二种方法是设置SYNCookie，就是给每一个请求连接的IP地址分配一个Cookie，如果短时间内连续受到某个IP的重复SYN报文，就认定是受到了攻击，并记录地址信息，以后从这个IP地址来的包会被一概丢弃。这样做的结果也可能会影响到正常用户的访问。上述的两种方法只能对付比较原始的SYNFlood攻击，缩短SYNTimeout时间仅在对方攻击频度不高的情况下生效，SYN Cookie更依赖于对方使用真实的IP地址，如果攻击者以数万/秒的速度发送SYN报文，同时利用SOCK_RAW随机改写IP报文中的源地址，以上的方法将毫无用武之地。

这是我网络中找的参考，希望对你有帮助。 在多线程任务中，TCP任务通过三次握手能建立可靠的连接，但是经常会发生在数据传输或通信时发生网络突然断开或者长时间连接空循环监听而未进行操作，需要在软件设计时考虑程序运行中检测到服务器对客户端的这一“虚连接”现象。如果主机崩溃，write是否阻塞取决于内核的tcp缓冲区，但read将一直阻塞，直到超时ETIMEOUT，或由于某些中间路由器的原因返回EHOSTUNREACH/ENETUNREACH。select不能检测到该情况。如果主机崩溃并重起，客户的write到达主机时主机响应RST，客户的read将返ECONNRESET。此处的”非正常断开”指TCP连接不是以优雅的方式断开,如网线故障等物理链路的原因,还有突然主机断电等原因。心跳机制有两种方法可以检测:1.TCP连接双方定时发握手消息2.利用TCP协议栈中的KeepAlive探测第二种方法简单可靠,只需对TCP连接两个Socket设定KeepAlive探测,所以本文只讲第二种方法在Linux,Window2000下的实现(在其它的平台上没有作进一步的测试)1）Windows平台C代码//定义结构及宏struct TCP_KEEPALIVE {u_longonoff;u_longkeepalivetime;u_longkeepaliveinterval;} ;#define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4)//KeepAlive实现TCP_KEEPALIVE inKeepAlive = {0}; //输入参数unsigned long ulInLen = sizeof(TCP_KEEPALIVE);TCP_KEEPALIVE outKeepAlive = {0}; //输出参数unsigned long ulOutLen = sizeof(TCP_KEEPALIVE);unsigned long ulBytesReturn = 0;//设置socket的keep alive为5秒，并且发送次数为3次inKeepAlive.onoff = 1;inKeepAlive.keepaliveinterval = 5000; //两次KeepAlive探测间的时间间隔inKeepAlive.keepalivetime = 5000; //开始首次KeepAlive探测前的TCP空闭时间if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS,(LPVOID)&inKeepAlive, ulInLen,(LPVOID)&outKeepAlive, ulOutLen,&ulBytesReturn, NULL, NULL) == SOCKET_ERROR){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) WSAIoctl failed. error code(%d)!n"), WSAGetLastError()));}//定义结构及宏 struct TCP_KEEPALIVE { u_longonoff; u_longkeepalivetime; u_longkeepaliveinterval; } ; #define SIO_KEEPALIVE_VALS _WSAIOW(IOC_VENDOR,4) //KeepAlive实现 TCP_KEEPALIVE inKeepAlive = {0}; //输入参数 unsigned long ulInLen = sizeof(TCP_KEEPALIVE); TCP_KEEPALIVE outKeepAlive = {0}; //输出参数 unsigned long ulOutLen = sizeof(TCP_KEEPALIVE); unsigned long ulBytesReturn = 0; //设置socket的keep alive为5秒，并且发送次数为3次 inKeepAlive.onoff = 1; inKeepAlive.keepaliveinterval = 5000; //两次KeepAlive探测间的时间间隔 inKeepAlive.keepalivetime = 5000; //开始首次KeepAlive探测前的TCP空闭时间 if (WSAIoctl((unsigned int)s, SIO_KEEPALIVE_VALS, (LPVOID)&inKeepAlive, ulInLen, (LPVOID)&outKeepAlive, ulOutLen, &ulBytesReturn, NULL, NULL) == SOCKET_ERROR) { ACE_DEBUG ((LM_INFO, ACE_TEXT ("(%P|%t) WSAIoctl failed. error code(%d)!n"), WSAGetLastError())); }2）Linux平台C代码#include……////KeepAlive实现//下面代码要求有ACE,如果没有包含ACE,则请把用到的ACE函数改成linux相应的接口int keepAlive = 1;//设定KeepAliveint keepIdle = 5;//开始首次KeepAlive探测前的TCP空闭时间int keepInterval = 5;//两次KeepAlive探测间的时间间隔int keepCount = 3;//判定断开前的KeepAlive探测次数if(setsockopt(s,SOL_SOCKET,SO_KEEPALIVE,(void*)&keepAlive,sizeof(keepAlive)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) setsockopt SO_KEEPALIVE error!n")));}if(setsockopt(s,SOL_TCP,TCP_KEEPIDLE,(void *)&keepIdle,sizeof(keepIdle)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPIDLE error!n")));}if(setsockopt(s,SOL_TCP,TCP_KEEPINTVL,(void *)&keepInterval,sizeof(keepInterval)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t) setsockopt TCP_KEEPINTVL error!n")));}if(setsockopt(s,SOL_TCP,TCP_KEEPCNT,(void *)&keepCount,sizeof(keepCount)) == -1){ACE_DEBUG ((LM_INFO,ACE_TEXT ("(%P|%t)setsockopt TCP_KEEPCNT error!n")));}心跳机制：定时发送一个自定义的结构体(心跳包)，让对方知道自己还活着，以确保连接的有效性。网络中的接收和发送数据都是使用WINDOWS中的SOCKET进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实TCP中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那TCP就会在一定的时间（比如你设置的是3秒钟）内发送你设置的次数的心跳（比如说2次），并且此信息不会影响你自己定义的协议。所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”。以确保链接的有效性。所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可以是客户也可以是服务端，看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项。系统默认是设置的是2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。心跳包一般来说都是在逻辑层发送空的包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀当然，这个自然是要由逻辑层根据需求去做了。总的来说，心跳包主要也就是用于长连接的保活和断线处理。一般的应用下，判定时间在30-40秒比较不错。如果实在要求高，那就在6-9秒。TCP连接异常断开后操作系统会告诉你，你查询套接字的状态会得到异常，或者当发现函数失败WSAGetLastError的时候也会得到内核的通知。// 发送回应消息int nSend = Send4IntMsg(sock, (char*)(LPCTSTR)strSendBuf,strSendBuf.GetLength(), errMsg);if (nSend < 0) //发送消息失败closesocket(sock);//重新连接 在B/S编程和UDP编程时才用到心跳。比如定期向web服务器发一个request证明自己在线。http协议是请求一下就断开了，每次都要重新连接，重新请求，这种情况下才有必要用心跳机制。一般的TCP通信都是长连接，不可能频繁连接和断开。对于长期保持连接的情况，一旦断开，操作系统底层都会通知你，你需要解决的是如何获取到系统的通知。
TCP/IP 指传输控制协议/因特网互联协议（Transmission Control Protocol / Internet Protocol），又名网络通讯协议