TCP之RST报文段

TCP 首部中的 RST 比特是用于 "复位" 的。一般来说,无论何时一个报文段发往基准的连接(referenced connection)出现错误,TCP 都会发出一个复位报文段("基准的连接" 指由目的 IP 地址和目的端口号以及源 IP 地址和源端口号指明的连接)。

1. 到不存在的端口的连接请求

产生复位的一种常见情况是当连接请求达到时,目的端口没有进程正在监听。对于 UDP,当一个数据报到达目的端口时,该端口没有在使用,它将产生一个 ICMP 端口不可达的信息。而 TCP 则使用复位。

如下示例,客户端向目的端口 1935 发送连接请求的起始包 "SYN",但是端口为 1935 的服务器并没有启动,此时 TCP 回复客户端 RST 报文。

C: SYN -> S(1935)

S(1935): RST -> C

2. 异常终止一个连接

终止一个连接的正常方式是一方发送 FIN,有时这也称为有序释放(orderly release),因为在所有排队数据都已发送之后才发送 FIN,正常情况下没有任何数据丢失。但也有可能发送一个复位报文段而不是 FIN 来中途释放一个连接,有时称这为异常释放(abortive relase)。

异常终止一个连接对应用程序来说有两个优点:

  1. 丢弃任何待发送数据并立即发送复位报文段;
  2. RST 的接收方会区分另一端执行的是异常关闭还是正常关闭。应用程序使用的 API 必须提供产生异常关闭而不是正常关闭的手段。

socket API 通过 "linger on close" 选项(即 SO_LINGER)提供了这种异常关闭的能力。

3. 检测半打开连接

如果一方已经关闭或异常终止连接而另一方却还不知道,我们将这样的 TCP 连接称为半打开(Half-Open)。任何一端的主机异常都可能导致这种情况发生。只要不打算在半打开连接上传输数据,仍处于连接状态的一方就不会检测另一方已经出现异常。

半打开连接的另一种常见原因是当客户主机突然掉电而不是正常的结束客户应用程序后再关机。

点赞
收藏

评论区

加载中...

相关推荐

MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1

文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s

Oracle 分组与拼接字符串同时使用

SELECTT.,ROWNUMIDFROM(SELECTT.EMPLID,T.NAME,T.BU,T.REALDEPART,T.FORMATDATE,SUM(T.S0)S0,MAX(UPDATETIME)CREATETIME,LISTAGG(TOCHAR(

MySQL部分从库上面因为大量的临时表tmp_table造成慢查询

背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_

手写Java HashMap源码

HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22

2020年前端实用代码段,为你的工作保驾护航

有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )

TCP的三次握手与四次挥手

TCP的三次握手与四次挥手一、TCP(TransmissionControlProtocol传输控制协议)TCP是面向对连接,可靠的进程到进程通信的协议TCP是提供全双工服务,即数据可在同一时间双向传输二、TCP报文段(封装在IP数据报