监控tcp连接目的(TCP连接中最后一次确认目的是)

导语：TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。本文介绍TCP发展过程中出现的几种拥塞控制算法，并着重介绍BBR的原理。TCP拥塞控制不仅仅是网络层的概念，可以将其归属于控制论的范畴。在TCP的演进过程中，出现了很多优秀的思想和算法，以实现网络传输过程中，在公平竞争性的前提下，尽可能地利用带宽资源。公平性是在发生拥塞时各源端（或同一源端建立的不同TCP连接或UDP数据报）能公平地共享同一网络资源（如带宽、缓存等）。处于相同级别的源端应该得到相同数量的网络资源。产生公平性的根本原因在于拥塞发生必然导致数据包丢失，而数据包丢失会导致各数据流之间为争抢有限的网络资源发生竞争，争抢能力弱的数据流将受到更多损害。因此，没有拥塞，也就没有公平性问题。TCP层上的公平性问题表现在两方面：（1）面向连接的TCP和无连接的UDP在拥塞发生时对拥塞指示的不同反应和处理，导致对网络资源的不公平使用问题。在拥塞发生时，有拥塞控制机制的TCP会按拥塞控制步骤进入拥塞避免阶段，从而主动减小发送到网络的数据量。但对无连接的数据报UDP，由于没有端到端的拥塞控制机制，即使网络出现了拥塞，也不会减少向网络发送的数据量。结果遵守拥塞控制的TCP数据流得到的网络资源越来越少，没有拥塞控制的UDP则会得到越来越多的网络资源。（2）TCP连接之间也存在公平性问题。产生问题的原因在于使用了不同的拥塞控制算法，一些TCP在拥塞前使用了大窗口尺寸，或者它们的RTT较小，或者数据包比其他TCP大，这样它们也会多占带宽。拥塞控制主要包括四个过程：1）慢启动；2）拥塞避免；3）拥塞发生；4）快速恢复。RTT：数据包从发出去到收到对它的ack的来回时间，采用平滑方式计算RTTRTO：重传超时。简单的如RTO=n*RTT, n=3（或其他RTO计算方法）SACK：TCP Option携带多组ACK信息FR：Fast Retransmission，收到3个dup ack后，即可认为发生了丢包。不需要等待RTO超时即可重传丢失的包。ER：Early Retransmission，无法产生足够的dupack和没有新的数据包可以发送进入网络的情况下，减少触发FR的dup ack数量，以达到触发FR的目的。TLP：如果发生了尾丢包，由于尾包后面没有更多的数据包，也就没有办法触发任何的dupack。实际上，Google统计超过70%的RTO是尾丢包导致没有任何dupack。TLP算法是通过发送一个loss probe包，来产生足够的SACK/FACK的信息以触发RF。Pacing：控制发送速率，防止bursting流控：Flow control站在单条TCP连接的维度，目的是让发送方发包的速度，不超过接收方收包的能力。所以流控解决的问题是，如何在接收方可承受的范围内，让单条 TCP 连接的速度最大化。通过滑动窗口机制实现。拥塞控制：Congestion control站在整个互联网的维度，让网络里所有TCP连接最大化共享网络通道的同时，尽可能的少出现网络拥塞现象，让网络世界里的每一个参与者既公平又高效。cwnd：发送窗口，拥塞窗口；在拥塞控制过程中窗口大小值变化。rwnd：接收窗口，通知发送者能够发送的数据大小。sliding window：滑动窗口，只是一种抽象机制概念；在发送请求及收到ack的过程中滑动。历史上出现的各种TCP拥塞控制算法，其本质是针对拥塞控制的四个过程做策略调整。按照算法依据的因素，可以简单的分为以下类型：因为Reno等算法是后续算法的基础，这里详细的描述下Reno算法的过程。（1）慢热启动算法 – Slow Start（2）拥塞避免算法 – Congestion Avoidance当cwnd >= ssthresh时，就会进入“拥塞避免算法”。算法如下：（3）拥塞状态算法 – Fast RetransmitTahoe是等RTO超时，FR是在收到3个duplicate ACK时就开启重传，而不用等到RTO超时。拥塞发生时：（4）快速恢复 – Fast RecoveryReno算法以其简单、有效和鲁棒性，应用最广泛。该算法所包含的慢启动、拥塞避免和快速重传、快速恢复机制，是现有的众多算法的基础。从Reno运行机制中很容易看出，为了维持一个动态平衡，必须周期性地产生一定量的丢失，再加上AIMD机制--减少快，增长慢，尤其是在大窗口环境下，由于一个数据报的丢失所带来的窗口缩小要花费很长的时间来恢复，这样，带宽利用率不可能很高且随着网络的链路带宽不断提升，这种弊端将越来越明显。另外，丢包并不一定是网络拥塞，可能是网络常态，但是基于丢包的拥塞控制并不能区分。vegas通过对RTT的非常重的监控来计算一个基准RTT。然后通过这个基准RTT来估计当前的网络实际带宽，如果实际带宽比我们的期望的带宽要小或是要多的活，那么就开始线性地减少或增加cwnd的大小。中间路由器缓存数据导致RTT变大，认为发生拥塞；RTT不公平性，当不同的数据流对网络瓶颈带宽进行竞争时，具有较小RTT的TCP数据流的拥塞窗口增加速率将会快于具有大RTT的TCP数据流，从而将会占有更多的网络带宽资源。在发送端做带宽估计，当探测到丢包时，根据带宽值来设置拥塞窗口、慢启动阈值。 那么，这个算法是怎么测量带宽的？每个RTT时间，会测量一次带宽，测量带宽的公式很简单，就是这段RTT内成功被ACK了多少字节。Westwood会根据RTT变化来判断丢包是否是网络拥塞造成的，还是网络常态的丢包。如果时延变化不明显，就认为是非网络拥塞，此时cwnd减少的比较小。BIC-TCP是Linux 2.6.18默认拥塞控制算法，依赖丢包条件触发。BIC-TCP认为TCP拥塞窗口调整的本质就是找到最适合当前网络的一个发送窗口，为了找到这个窗口值，TCP采取的方式是(拥塞避免阶段)每RTT加1，缓慢上升，丢包时下降一半，接着再来慢慢上升。BIC-TCP的提出者们看穿了事情的本质，其实这就是一个搜索的过程，而TCP的搜索方式类似于逐个遍历搜索方法，可以认为这个值是在1和一个比较大的数(large_window)之间，既然在这个区间内需要搜索一个最佳值，那么显然最好的方式就是二分搜索思想。BIC-TCP就是基于这样一个二分思想的：当出现丢包的时候，说明最佳窗口值应该比这个值小，那么BIC就把此时的cwnd设置为max_win，把乘法减小后的值设置为min_win，然后BIC就开始在这两者之间执行二分思想--每次跳到max_win和min_win的中点。BIC也具备RTT的不公平性。RTT小的连接，窗口调整发生的速度越快，因此可能更快的抢占带宽。CUBIC在设计上简化了BIC-TCP的窗口调整算法，在BIC-TCP的窗口调整中会出现一个凹和凸(这里的凹和凸指的是数学意义上的凹和凸，凹函数/凸函数)的增长曲线，CUBIC使用了一个三次函数(即一个立方函数)，在三次函数曲线中同样存在一个凹和凸的部分，该曲线形状和BIC-TCP的曲线图十分相似，于是该部分取代BIC-TCP的增长曲线。另外，CUBIC中最关键的点在于它的窗口增长函数仅仅取决于连续的两次拥塞事件的时间间隔值，从而窗口增长完全独立于网络的时延RTT，使得连接之间保持良好的RRTT公平性。来看下具体细节：当某次拥塞事件发生时，Wmax设置为此时发生拥塞时的窗口值，然后把窗口进行乘法减小，乘法减小因子设为β，当从快速恢复阶段退出然后进入到拥塞避免阶段，此时CUBIC的窗口增长开始按照“凹”式增长曲线进行增长，该过程一直持续直到窗口再次增长到Wmax，紧接着，该函数转入“凸”式增长阶段。该方式的增长可以使得窗口一直维持在Wmax附近，从而可以达到网络带宽的高利用率和协议本身的稳定性。CUBIC窗口的增长函数：W(t) = C * (t-K)3 + Wmax, 其中C和β为常量。t为当前时间距上一次窗口减小的时间差，而K就代表该函数从W增长到Wmax的时间周期。通俗一点讲，假如我们知道了Wmax，那么CUBIC的核心思想就是需要在连续两次拥塞期间执行完上面的三次函数增长曲线BBR通过实时计算带宽和最小RTT来决定发送速率pacing rate和窗口大小cwnd。完全摒弃丢包作为拥塞控制的直接反馈因素。传统的拥塞控制算法是计算cwnd值来规定当前可以发送多少数据，但是并不关注以什么样的速度发送数据。如果简单而粗暴地将窗口大小（send.cwnd、recv.cwnd的最小值）数据全部突发出去，这往往会造成路由器的排队，在深队列的情况下，会测量出rtt剧烈地抖动。bbr在计算cwnd的同时，还计算了一个与之适配的pacing rate，该pacing rate规定cwnd指示的一窗数据的数据包之间，以多大的时间间隔发送出去。我们知道，网络工作的最优点是在物理链路延迟状态下，以最大速率传输数据。传统的拥塞控制算法思想是根据数据传输及ACK来确定RTT，但是这个RTT并不是物理链路延时，可能包含了路由器缓存耗时，也可能是拥塞状态下的耗时。传统的带宽计算也是在不断的试探逼近最优发送窗口，并在RTT或者统计周期内计算带宽。这种情况下，RTT并不是真正的物理链路延迟，带宽也有可能是在有路由缓存或丢包状况下计算得到，那么必然得到的不是精准的值。BBR摒弃了丢包和实时RTT作为拥塞控制因素。引入BDP管道容量来衡量链路传输水平。BBR追求的是在链路最小RTT（物理链路延迟）的状态下，找到最大带宽。首先我们认为网络最优点是可以达到的。下面描述RTT及收包速率与数据包投递速率的关系。图中上半部分的过程可以描述为：随着数据包投递速率增加，如果没有超过最优带宽，则RTT不会变化，此时的RTT是物理链路延迟。随着投递速率继续增加，这时中间路由节点可能出现需要缓存数据包的情况，这会导致RTT变大。如果投递速率继续增加，超过路由缓存能力，则可能出现丢包。图中下半部分的过程可以描述为：随着数据包投递速率增加，如果没有超过最优带宽，则发送方确认接收端收到的数据速率增加。随着投递速率继续增加，因为数据包缓存在中间路由，这些包并不能及时得到ACK，因此发送方得到的ACK速率，即发送发确认接收方收到数据的速率会维持不变。如果投递速率继续增加，超过路由缓存能力，则可能出现丢包。1）应答了多少数据，记为delivered；2）应答1）中的delivered这么多数据所用的时间，记为interval_us。将上述二者相除，就能得到带宽：bw = delivered/interval_us；该计算方法不关注数据包ack及顺序，是纯粹的标量。我们可以根据图示很容易算出从Delivered为7时的数据包被确认到X被确认为止，一共有12-7=5个数据包被确认，即这段时间网络上清空了5个数据包。我们便很容易算出带宽值了。当10s内没有发现最小RTTProp时，就要进入ProbeRTT状态。在ProbeRTT状态，仅发4MSS/RTT(接近停止发送)，从而排空链路上的数据包，测量真实的RTTProp。这里带来的一个问题是，在一个RTT时间内以4MSS速率发送可能会造成抖动，特别是长RTT场景。具体的参考willko文章《GBN手札-BBR实时大数据传输之痛》。

针对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万以上的同时连接数的容量，为数据传输的高效和可靠提供了强有力地保障。
如果是使用宽带方式上网，那么在注册表中设定适当的TcpWindow值，就可以加快上网速度。 打开注册表编辑器，在其中 找到“HKEY_LOCAL_MACHINE＼System＼CurrenControlSet＼Services＼Tcpip＼Parameters”子键，在右边键值区中，找到或新建一个名为“GlobalmaxTcp WindowSize”的DWORD键值项，将其数据值数据设为“256960”(十进制)，关闭注册表编辑器，重新启动电脑即可。 感觉一下是不是速度比以前快多了？ 这个更改的原理是：通常情况下，TCP/IP默认的数据传输单元接受缓冲区的大小为576字节，要是将这个缓冲区的大小设置得比较大的话，一旦某个TCP/IP分组数据发生错误时，那么整个数据缓冲区中的所有分组内容，都将被丢失并且进行重新传送；显然不断地重新进行传输，会大大影响ADSL传输数据的效率。为此，设置合适缓冲区大小，确保ADSL传输数据的效率始终很高，将会对ADSL传输速度有着直接的影响！
给电脑一个固定的IP，不让IP冲突 电脑不能上网时也可以通过这里来解决

你都知道端口映射了。那么DDNS有在用吗？还是你这边是有固定IP的。 是不是这个问题？ tcp和udp是给手机远程监控用的端口号。看这个端口号，是用大华的录像机吧。另外会不会是用IE浏览器远程监控的问题。浏览器安全设置会阻止安装监控插件。 并且很多浏览器不支持监控界面。
不管你的外网IP是固定IP还是动态IP,你在路由器中需要设置允许广域网中所有的计算机都可以登录路由器执行远端WEB管理,除非你需要执行管理的那台电脑的IP也是公网的固定IP。其次，如果是动态IP，建议你申请一个花生壳动态域名，然后在路由器里面设置一下DDNS，把你申请的东西添加进去，这样差不多就可以了
你的tcp/ip协议没有装正确 只要tcp/ip协议安装正确了，即使没的网卡，ping127.0.0.1都是通的 这个ip就是用来测试用的

TCP并发连接数就是防止死传输的线程，A线程不可用，就自动选择B线程连接~ 这个不行用那个~就是这作用~TCP连接数量越大，尝试成功可能性越大！ 自己比喻~不好请不要见怪！
众所周知，为了防范蠕虫病毒的传播和攻击，Windows XP SP2将并发线程最多限制为10个。SP2利用Messages动态链接库，来实时监控每个进程的并发线程数目，一旦它发现某进程的线程数超过10个，就会屏蔽掉部分线程。SP2这样做，虽然可以防范震荡波类型的蠕虫病毒，加强系统安全，但是也带了一些负面影响，例如当你使用BT、P2P或FlashGet软件下载时，部分线程将被屏蔽掉，因此下载速度会变得很慢。为此，你可以采取以下对策，来突破TCP并发连接数，从而提高SP2的多线程访问速度。

不知道你说的是不是TCP/IP模型的网络接口层 如果是，它相当于OSI模型的数据链路层和物理层两个部分其中数据链路层的作用是规定如何将数据包转化成网络硬件可传输的形式（数据帧），并从一个网络接口传递到下一个网络接口。提供传递两端的源物理地址和目的物理地址，并能识别网络拓扑，控制数据流实现面向连接的或非面向连接的传输。物理层用于定义过程中使用何种类型的传输介质、连接器、信号等。 希望能帮到你。
不知道你说的是不是TCP/IP模型的网络接口层 如果是，它相当于OSI模型的数据链路层和物理层两个部分其中数据链路层的作用是规定如何将数据包转化成网络硬件可传输的形式（数据帧），并从一个网络接口传递到下一个网络接口。提供传递两端的源物理地址和目的物理地址，并能识别网络拓扑，控制数据流实现面向连接的或非面向连接的传输。 物理层用于定义过程中使用何种类型的传输介质、连接器、信号等。
相当于OSI模型物理层、数据链路层的功能综合，TCP/IP协议是根据OSI参考模型的标准开发的一个协议实例，对OSI规定的内容进行了精简，当然OSI规定只是一种理想情况，目前没有协议完全达到