tcp没建立成功(Tcp建立连接)

tcp 建立失败,会有什么影响 TCP to establish failure, can have what effect

1、如果服务器/客户端IP不在一个网段，是否TCP/IP就无法按常规手段输送数据； 正常方法是可以的，但因为要兼顾网段，中转在客户端还是在服务器端就是问题了2、如果服务器IP固定，客户端IP通过路由设定，是否TCP/IP就无法按常规手段输送数据；不同路由内置防火墙拦截不同因素，常规手段肯定不行3、如果熟悉WIN2003服务器版，是否常规安装的WIN2003的服务器，用我的方法在TCP/IP方式就无法按常规手段输送过去数据 貌似同NT遍历的原因，PING包到了之后服务器不响应
一楼的好长呀，但一点也不挂边呀！ 我的解释：1、如果服务器/客户端IP不在一个网段，是否TCP/IP就无法按常规手段输送数据；正常方法是可以的，但因为要兼顾网段，中转在客户端还是在服务器端就是问题了2、如果服务器IP固定，客户端IP通过路由设定，是否TCP/IP就无法按常规手段输送数据；不同路由内置防火墙拦截不同因素，常规手段肯定不行3、如果熟悉WIN2003服务器版，是否常规安装的WIN2003的服务器，用我的方法在TCP/IP方式就无法按常规手段输送过去数据貌似同NT遍历的原因，PING包到了之后服务器不响应 应该是这个样子的！
我还一楼的是SB啊这也叫回答？ 楼主你要确定是不是TCP协议的问题首先想问你确定是 TCP还是UDP确定好了之后 做一个数据发送的测试看看丢包率高不高当然用相应的协议 你也知道TCP和UDP的机制是有所不同的确定好 包的传送效率后你在服务器 和你的客户端两边抓一包 注意抓的是你的软件的数据包分析一下看是否有问题一步一步都排除了要是传送率很稳定两包抓的包解析后 也是正常的数据那么检查系统了 也没到那个实际环境能帮你分析的差不多就这吧 呵呵
我想到了一个，不知对不对。存在第三方主机通过一定手段截取了客户端发送的数据。客户端数据没有到达服务端。 老师告诉我们，要理清思路。我认为可以这么分析： 人为因素，客观因素，不可抗因素，然后在逐个分析。
U （URG） Urgent pointer field significant 紧急指针,用到的时候值为,用来处理避免TCP数据流中断 拉~~
不在一个网段可以通过网关转发,网关可以连接起2个不同的网段 防火墙干扰的可能性比较大 另外在TCP/IP的高级选项里有ip及端口过滤的选项 一般是不怎么用的 就有你的小程序有没有bug呢,你可以用现有的一些程序做测试 比如TCP-UDP服务管理TCP&UDP测试工具 等 需要的话可以我可以提供

2006.12.28.卡巴斯基实验室 卡巴斯基提供紧急升级服务站点，解决病毒库升级问题 近日，受我国台湾省发生强地震的影响，多条国际海底通信光缆发生中断，中断点位于台湾以南15公里的海域，造成附近国家和地区的国际和地区性通信受到严重影响。由此，部分卡巴斯基用户无法链接到卡巴斯基全球服务器，不能进行病毒数据库升级。为最大限度的消除地震给国内正版用户带来的不利影响，保证用户的病毒数据库可以正常升级，卡巴斯基（中国）公司于12月29日起，向中国用户开放紧急升级站点，用户可通过此站点在非常时期手动进行病毒数据库升级。无法在紧急升级站点更新病毒数据库的用户，还可在卡巴斯基中国官方网站和合作伙伴网站下载“病毒数据库离线更新包”，进行离线更新，保障个人信息财产安全。 卡巴斯基（中国）竭力在非常时期为广大用户提供更好的紧急解决方案，全力保护用户的信息安全。在网络恢复正常后，请用户再用默认设置进行升级。感谢所有用户对卡巴斯基的理解和支持！ 使用紧急升级站点步骤（仅适用于6.0个人版用户）： 1、在“服务”-〉“更新”上点鼠标右键，选择“设置”； 2、在“更新设置”中选择“自定义”按钮； 3、在弹出的对话框中，选择“更新服务器”标签； 4、点击“添加”按钮，在“源”后的方框中加入“ http://dnl-cdn.kaspersky-labs.com ”，点击“确定”； 5、退回到“更新服务器”标签下，去掉“卡巴斯基实验室更新服务器”前面的勾。如果之前使用了离线升级包的方式进行升级，也请去掉相应的离线升级包前的勾，选择确定；； 6、进行升级。 提示：由于升级用户数量众多，造成网络拥塞，如使用此方法升级一次不成功，请多试几次，或选在升级用户较少的时间进行升级！ 离线更新的操作步骤： 1、在“服务”-〉“更新”上点鼠标右键，选择“设置”； 2、在“更新设置”中选择“自定义”按钮； 3、在弹出的对话框中，选择“更新服务器”标签； 4、点击“添加”按钮，选择本地更新文件，同时勾选“正在从文件夹或ZIP文档中更新”，点击“确定”； 5、退回到“更新服务器”标签下，去掉“卡巴斯基实验室更新服务器”前面的勾，选择确定； 6、进行升级。
使用LNS 2.06中也有"TCP 全状态包检测: 无法建立连接"信息但没发现对网络有什麽影响。
我这边可是出现这个就会网络断开上不了网。

如测试别人电脑端口 在你电脑上 telnet 192.168.1.221 5000端口开了 黑屏光标闪 或下个TCP端口软件 输入ip和端口号 点连接 有提示是否成功

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次连接通信过程中必不可少的。因此，运输连接就有三个阶段：连接建立，数据传送和连接释放。需要解决以下3个问题：连接建立这个过程，需要在客户端和服务器之间，交换3个TCP报文段，也就是三次握手????x3。????请注意，在本例中，A主动打开连接，B被动打开连接一开始，B就在准备接受客户进程的连接请求，然后服务器进程就处于 LISTEN （收听）状态，等待客户的连接请求。如有，即作出响应。A的TCP客户进程像B发出连接请求报文段，这时，首部中的同步位SYN = 1，同时选择一个初始序号 seq = x 。TCP规定????，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。B收到连接请求的报文段后，如同意建立连接，则向A发送确认。在确认报文段中，应把SYN位和ASK位都置1，确认号是 ack = x + 1 ，同时也为自己选择一个初始序号 seq = y 。请注意，这个报文段也不能携带数据。但同样要消耗掉一个序号。这时，TCP服务器进程进入SYN-RCVD（同步收到）状态。TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号 ack = y + 1 ，而自己的序号 seq = x + 1 。TCP的标准规定????，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x +1 。这时，TCP连接已经建立????，A进入ESTABLISHED（已建立连接）状态。当B收到A的确认后，也进入ESTABLISHED（已建立连接）???? Q:为什么A最后还有发送一次确认呢？????A:主要是为了防止已失效的连接请求报文段突然又传送到B，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。????考虑一种正常情况，A 发出连接请求????，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发出了两个连接请求的报文段，其中第一个丢失????，第二个到达了B????，没有“已失效的连接请求报文段”。????现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留????，以至延误到连接释放以后的某个时间才到达B。本来这是一个 早已失效的报文段 ，但是B收到此时小的连接请求的报文段之后，误以为是A又发出一次新的连接请求。于是向A发出确认报文段，同意建立连接。假定不采用报文握手。那么只要B发出确认之后，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认????，也不会向B发送数据，但B确以为新的运输连接已经建立，并一直等待A发来的数据。B的许多资源就这样白白浪费了。