- 综合排序
- 最热优先
- 最新优先
- 来自专栏全栈程序员必看
TCP连接异常终止（RST包）场景分析
一、TCP异常终止（reset报文） TCP的异常终止是相对于正常释放TCP连接的过程而言的，我们都知道，TCP连接的建立是通过三次握手完成的，而TCP正常释放连接是通过四次挥手来完成。 如果此时不通过其他的方式来释放TCP连接的话，这个TCP连接将会一直存在，占用系统的资源。在这种情况下，我们就需要有一种能够释放TCP连接的机制，这种机制就是TCP的reset报文。 reset报文是指TCP报头的标志字段中的reset位置一的报文，如下图所示： 二、TCP异常终止的常见情形 我们在实际的工作环境中，导致某一方发送reset报文的情形主要有以下几种： 1. 客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送TCP reset报文，告之对方释放相关的TCP连接，如下图所示： 3. 安全设备利用reset报文阻断异常连接 安全设备（如防火墙、入侵检测系统等）在发现某些可疑的TCP连接时，会构造交互双方的reset报文发给对端，让对端释放该TCP连接。
7.2K51编辑于 2022-11-15 - 来自专栏余子军的专栏
Linux 2.6.16 TCP 连接速度异常的问题分析
分析认为SESU10母盘上内核TCP拥塞控制算法和Windows的Ack频率控制的策略存在不兼容情况。 目前至少确认 2.6.16内核版本存在此问题，打TCP优化补丁或者更换Tlinux以后可以解决问题。 服务器程序： Apache，nws（自研webserver） 客户端： Windows XP， Windows7，任意浏览器或者旋风（单线程下载） 测试工具：wireshark， httpwatch 测试连接 Linux这一端，首先怀疑和nagle算法有关系，在nws服务器上设置TCP_NODELAY以后仍然可以重现，可以排除Nagle算法的影响。 通过测试增大初始拥塞窗口为10 （更换内核加载架平新技术组的TCP优化模块实现），下载速度恢复正常。
5.4K00发布于 2016-09-21 - 来自专栏移动开发的那些事儿
DHCP租约到期自动续租问题导致TCP连接异常
连接来说，使用旧的过期ip就意味着连接不到远程服务器，从我们的日志信息中可以得知，当TCP使用过期的ip去连接远程服务器的时候会报如下异常：java.net.NoRouteToHostException : No route to host，意思是说没有可达Host的路由，确实是这样的，设备连接无线网是连接到路由器上的，而路由器上分配给设备的ip已经过期不可用，那么设备到路由器的链路是通的，但是路由器到远程主机的链路肯定是不通的 连接是一直报java.net.NoRouteToHostException: No route to host异常，如果TCP当前正处于连接中，那么DHCP的更新可能会导致TCP断线，等到后面设备发起的 DHCP请求收到Ack之后，TCP连接立刻恢复正常，并且此时收到了网络切换广播，针对以上问题，如何恢复呢？ 搜索网上资料是说应用程序每次重新建立一条新的TCP的时候会触发设备请求DHCP Server，但是从我们的log查看发现并没有，请求DHCP Server没有Ack后设备会间隔重试，当设备被触发亮屏后，
5.2K40发布于 2018-09-04 - 来自专栏阿伟的个人博客
Tcp连接建立与连接释放
Tcp连接建立 ? 上图为Tcp连接建立过程： 1）客户端给服务器发送了一条将其SYN标志位置1的请求连接建立报文，然后其状态由closed转变为SYN-SENT（同步已发送）。 3）客户端收到该报文后，给服务器发送一条将ACK置为1的确认报文，之后就进入established状态（已建立连接）。 accept(); Tcp连接释放 ? 连接释放过程如上图所示. 1）客户端对服务器发送连接释放报文段将其FIN标志位置1，并由之前的established状态转化为finwait-1（终止等待1）状态。此时其已经不能再发送了，只能接收。 2）为了防止已失效的连接请求报文出现在本连接中。
4.9K40发布于 2020-08-25 - 来自专栏技术分享
面向数据连接:TCP
面向连接的传输： TCP TCP：概述 提供的是点对点的服务： 一个发送方，一个接收方 可靠的、按顺序的字节流 ： 没有报文边界 管道化（流水线）： TCP拥塞控制和流量控制设置 窗口大小 发送和接收 每层都要加上头部信息==]) 面向连接： 在数据交换之前，通过握手（交换控制报文） 初始化发送方、接收方的状态 变量 有流量控制： 发送方不会淹没接收方 段结构 TCP报文段结构 源端口号 因为握手已经结束， 所以Server并不知道你Client是否活跃，所以这就是所谓的半连接。 TCP 三次握手 基于2次握手的不可行性， 我们通过三次握手来实现解决。 基本方案是 ： 变化的初始序号+双方确认对方的序号（3次握手） Client建立起连接 。然后将自己的初始序号， x发送TCP SYN报文。 就不会出现老数据传输 TCP 三次握手 ： FSM TCP： 关闭连接 客户端，服务器分别关闭它自己这一侧的连接【通过发送FIN bit = 1的TCP段 】 一旦接收到FIN，用ACK回应 【
1.1K10编辑于 2024-05-31 - 来自专栏Golang语言社区
tcp自连接问题
sock = socket.socket(socket.AF_INET,socket.SOCK_STREAM) sock.setsockopt(socket.IPPROTO_TCP ,socket.TCP_NODELAY,1) sock.connect(('127.0.0.1',55555)) connected=True tcp自连接出现了！ 原因分析 从上面的python脚本中，可以看到它只是在不断地尝试连接55555这个端口，并且是没有socket监听这个端口，那么为何最后却建立连接了呢？ 因为对于tcp协议来讲，连接的流程是走的通，三次握手整个阶段都合法，连接自然可以建立。 自连接的坏处显而易见，当程序去connect一个不处于监听的端口时，必然期待其连接失败，如果自连接出现，就意味着该端口被占用了，那么： 真正需要监听该端口的服务会启动失败，抛出端口已被占用的异常。
2.9K70发布于 2018-03-22 - 来自专栏健程之道
TCP连接及其优化
作为一个后端程序员，网络连接这块是一个绕不过的砍，当你在做服务器优化的时候，网络优化也是其中一环，那么作为网络连接中最基础的部分- TCP连接你了解吗？今天我们来仔细看看这个部分。 TCP建立连接-三次握手 详解 ? .tcp_max_syn_backlog 被动建立连接时，发SYN/ACK（步骤3）重试次数 net.ipv4.tcp_synack_retries 说完了TCP建立连接，接下来，我们再来看看TCP正常断开连接的过程 TCP断开连接-四次挥手 详解 ? .tcp_fin_timeout = 60 总结 看到这里，想必你应该对TCP连接有了一个大致的了解。
2.4K20发布于 2019-11-02 - 来自专栏腾讯云开发者社区头条
TCP 异常关闭研究分析
作者：谢代斌 研究测试TCP断开和异常的各种情况，以便于分析网络应用（比如tconnd）断网的原因和场景，帮组分析和定位连接异常掉线的问题，并提供给TCP相关的开发测试人员作为参考。 结论：这种情况下服务器程序没有检测到任何异常，并最后等待“超时”才断开TCP连接。 当TCP连接的进程机器发生死机、系统突然重启、网线松动或网络不通等情况下 -（Windows客户端），连接的对端进程可能检测不到任何异常，并最后等待“超时”才断开TCP连接。 TCP异常进一步测试研究2.1 测试方法客户端和服务器端程序建立TCP连接，服务器程序在TCP缓冲区中有消息或没有消息的情况下关闭Socket，客户端在对端Socket已经关闭的情况下继续Send和Recv ，也会导致连接提前夭折使对端收到RST异常关闭消息。
10.1K00发布于 2016-09-28 - 来自专栏码农沉思录
聊聊TCP连接管理
我们今天要讲的TCP是属于运输层的协议，其特点是提供面向连接的可靠的数据传输，此外，TCP还提供了流量控制与拥塞控制等功能。 今天我们要讲的就是TCP的连接管理，即TCP如何建立连接与断开连接，后续文章再介绍TCP的其他特性。 TCP建立连接 TCP建立连接的过程也叫“握手”，“握手”需要在客户端和服务端之间交换3个TCP报文，所以也俗称“三次握手”，其过程如下： ? TCP断开连接 TCP断开连接相对复杂一点，总共分为4个步骤，俗称“四次挥手”。其过程如下： ? 数据传输结束后，双方都可以断开连接，现在假设客户端A主动断开连接。 A经过2MSL时间后，可以保证在本次连接中传输的报文段都在网络中消失，这样一来就能保证在后面的连接中不会出现旧的连接产生的报文段了。 以上就是TCP连接管理的内容了，后续还会继续介绍TCP的其他特性。
1.7K80发布于 2018-04-17 - 来自专栏haifeiWu与他朋友们的专栏
我理解的 TCP 连接
总述 TCP 是面向连接的协议。运输连接是用来传输 TCP 报文的。TCP 运输连接的建立和释放是每一次面向连接通信中必不可少的过程。因此，运输连接有三个阶段，即：连接建立，数据传输和连接释放。 如上图所示，上图画出了 TCP 的连接过程。假定主机 A 运行的是 TCP 客户程序，而B运行的是 TCP 服务器程序。最初两端的 TCP 进程都处于 CLOSE 状态。 图中在主机下面的方框中分别是 TCP 进程所处于的状态。请注意，A 主动打开链接，而 B 被动打开连接。 B的TCP服务器进程先创建传输控制快 TCB，准备接受客户进程的连接请求。 这时 TCP 连接建立完成，A 进入 ESTABLISHED（已建立连接）状态。 当 B 收到 A 的确认后，也进入 ESTABLISHED 状态。 TCP 连接的释放（四次挥手） ? 数据传输结束后，通信双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP 连接。
1.7K10发布于 2020-02-10 - 来自专栏elon带你死磕技术
关于TCP overflowed、全连接、半连接队列
背景 最近遇到多台CVM中客户端访问服务器端超时的异常，当时查看了netstat -as信息，凭经验判断可能是tcp overflowed导致的。 image.png 这里有两个队列： 半连接队列：SYN queue ，长度由tcp_max_syn_backlog和net.core.somaxconn和 业务tcp调用listen(fd, backlog 收到Client的ACK报文， 如果全连接队列未满，那么从半连接队列拿出相关信息放入到全连接队列中，进入ESTABLISHED状态 如果全连接队列满了并且tcp_abort_on_overflow是0的话 如果Client超时等待设置较短，就会引发异常 监控方法 netstat -as 如下图中所示信息： 全连接队列满了：xxx times the listen queue of a socket overflowed 半连接队列满了：xxx SYNs to LISTEN sockets dropped 可以通过监控数值是否增加，来判断是否存在异常 image.png 优化方式 调高 net.core.somaxconn
8.2K112发布于 2019-11-27 - 来自专栏陶士涵的菜地
使用tcpkill杀掉tcp连接
在使用长连接的过程中,如果有的长连接一直连着,想要杀掉这条连接可以使用tcpkill命令 安装tcpkill , tcpkill使用dsniff的一个小工具 apt install dsniff 使用过程 : 比如连接服务端8082端口的这条连接 ? 杀掉连接, 过滤规则类似tcpdump tcpkill -i any -9 host 49.7.40.205 ? 连接成功被杀掉 ?
8.6K20发布于 2020-08-24 - 来自专栏Super 前端
【HTTP】连接管理--TCP
TCP连接 TCP连接是因特网上的可靠连接 TCP为HTTP提供了一条可靠（是因为 确认延迟）的比特传输管道。从TCP连接一端填入的字节会从另一端以原有的顺序、正确的传送出来。 两条不同的TCP连接不能拥有4个完全相同的地址组件值。 HTTP要传送一条报文时，会以流的形式将报文数据的内容通过一条打开的TCP连接按序传输。 TCP慢启动 TCP连接会随着时间进行自我”调谐“，起初会限制连接的最大速度，如果数据成功传输，会随着时间的推移提高传输的速度，这种调谐称为TCP慢启动，用于防止因特网的突然过载或拥塞。 TIME_WAIT累计与端口耗尽 当某个TCP端点关闭TCP连接时，会在内存中维护一个小的控制块，用来记录最近所关闭连接的IP地址和端口号。 并行连接：通过多条TCP连接发起并发的HTTP请求； 持久连接：重用TCP连接，以消除连接及关闭时延； 管道化连接：通过共享的TCP连接发起并发的HTTP请求； 复用的连接：交替传送请求和响应报文。
1.7K22发布于 2019-08-14 - 来自专栏程序员奇点
TCP连接建立和释放
什么是TCP协议? TCP 是面向连接的，保证高可靠连性（数据无丢失，数据不错位，数据不乱序，数据无重复）的传输协议。 TCP头 ? TCP 规定，在连接建立后所有传输的报文都必须把 ACK 置1 推送PSH 当两个应用进程进行交互式通讯是，有时在一端的应用进程希望键入一个命令后立即就能收到对方的响应。在这种情况。 TCP 就可以使用推送 push 操作。 复位 RST 当 RST = 1时，表明 TCP 连接中出现严重的差错（如 由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。 TCP的特点 面向连接的传输层协议 每一条TCP连接只能有两个端点 提供可靠交付的服务 提供全双工通信 面向字节流 建立连接: TCP 三次握手 1. 断开连接：四次挥手 A 向 B 发送连接释放报文端，并停止发送数据，主动关闭 TCP 连接，报文端首部 FIN 设置成1 ，序号 seq = u ,它等于前面已经传输过来的最后一个自己的序号+1 B
2.3K40发布于 2019-08-13 - 来自专栏陶士涵的菜地
测试go连接imap的tcp长连接
连接上imap服务后，什么都不操作，我测试大约5分钟会被服务端断掉，测试代码如下 imapClient, _ := client.Dial("imap.sina.net:143") for { time.Sleep(time.Second * 1) } 为了保持住这条连接，每隔10秒列取一下邮件夹列表，这样就可以一直保持住连接了。 开三个窗口，一个窗口不停的netstat查看tcp连接情况，一个窗口运行代码，一个窗口打开tcpdump监听端口查看数据请求 while true;do clear;date;netstat -altupn
2.6K10发布于 2019-11-22 - 来自专栏sofu456
c# tcp异步连接
, port); m_listen.Start(); m_listen.BeginAcceptTcpClient(AcceptTcpClient, m_listen); //接收连接 } private void AcceptTcpClient(IAsyncResult ar) {//建立连接 TcpClient recClient = m_listen.EndAcceptTcpClient recClient.Client.BeginReceive(recData, 0, recData.Length, SocketFlags.None, RecieveDataAsyn, recClient);//接收连接
2.5K30发布于 2020-02-13 - 来自专栏算法之美
tcp如何维护长连接
上次提到tcp数据流无边界特点 还有一个特点那就是 TCP有长连接和短连接之分 目录结构： tcp连接的终止 — 01 — socke正常关闭 流程： 被动关闭一方接受完毕数据 然后发送 --断开连接 Q2 问题来了 如何减少TIME_WAIT时间 通过修改socket选项SO_LINGER 异常关闭连接 打破四次握手， 避免j进入TIME_WAIT状态 — 03 — 异常情况 TCP会在连接上发送一个FIN。 但是如果tcp连接的另一端突然掉线，或者重启断电，这个时候我们并不知道网络已经关闭。 而此时，如果有发送数据失败，tcp会自动进行重传。 即我们在重传超时后才知道连接失败. — 05 — 不直接通知异常 c++： 在程序中表现为,当tcp检测到对端socket不再可用时(不能发出探测包,或探测包没有收到ACK的 * 响应包),select
3.4K90发布于 2018-04-13 - 来自专栏后台技术底层理解
TCP 连接的细节问题
先来描述下三次握手连接： 第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB。 然后，在打算建立 TCP 连接时， 向 B 发出连接请求报文段，这时首部中的同步位 SYN=1，同时选择一个初始序号 seq = x。 这时，TCP 连接已经建立，A 进入 ESTABLISHED（已建立连接）状态。 为什么要三次握手？ TCP 连接使用三次握手的首要原因 —— 为了阻止历史的重复连接初始化造成的混乱问题，防止使用 TCP 协议通信的双方建立了错误的连接。 ，其中并不存在一个用于计数的全局时钟，而 TCP 可以通过不同的机制来初始化序列号，作为 TCP 连接的接收方我们无法判断对方传来的初始化序列号是否过期，所以我们需要交由对方来判断，TCP 连接的发起方可以通过保存发出的序列号判断连接是否过期
1.7K30发布于 2020-09-01 - 来自专栏杂烩
kafka连接异常 原
kafka版本是0.10.2.1 本地java客户端版本是0.8.1.1 主要两个错误 第一个是连接拒绝 kafka Connection refused: no further information
2.2K20发布于 2018-08-17 - 来自专栏学习
【TCP】相关机制：异常处理
进程崩溃 Java 中的体现就是抛出异常，但没人 catch，最终异常到了 JVM 这里，JVM 进程就会直接噶了。 四次挥手） 这样的情况看起来是异常，但实际上是一种正常情况，并不会有什么特殊处理，和正常关闭没有什么区别 2 . 接收方掉电 A 给 B 发送的数据，就不会再有 ACK 了 A 触发超时重传，重传的数据当然还是没有响应 反复多次之后，A 尝试重置连接（RST） 重置操作也没有 ACK，A 就会单方面释放连接（A 把保存的 B 的信息删除掉） TCP 正常断开，就是双方各自删除自己的（协议离婚） TCP 异常断开，就是只能删除自己的，不管对面了（起诉离婚，强制执行） 2. 问对方还在不在 这样的探测报文是周期性的，同时这个报文是用来探测对方“生死”的，也就把这样的报文称为“心跳包” 计算机中，非常广泛的使用“心跳包”的思想 TCP 内置了心跳包，由于 TCP 内置的心跳包周期比较长
38010编辑于 2024-10-15
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号