精华内容
下载资源
问答
  • TCP 半关闭

    2014-04-06 21:21:17
    TCP半关闭  TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力,这就是TCP半关闭。 客户端发送FIN,另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后,才发送FIN...
    TCP的半关闭
       TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力,这就是TCP的半关闭。
    客户端发送FIN,另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后,才发送FIN关闭这个方向的连接,客户端再对这个FIN确认,这个连接才彻底关闭。

    回顾TCP协议那些事儿 - [技术前沿]

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明

    http://bigwhite.blogbus.com/logs/11582229.html

    我不是计算机科班出身。记得大学的时候旁听计算机系的网络课,当时计算机系使用教材是"计算机网络--自顶向下方法与Internet特色"的影印版,这本教材与众不同的一个地方就是作者JAMES F.KUROSEKEITH W.ROSS采用了'自顶向下'的编排思路,先从应用层开始,最后讲到物理层。而且这本书在语言上形象生动,通俗易懂。只怪我当初没有一心一意听讲,到现在存在我的脑子中的基本概念居多,深刻理解甚少。以致于工作后遇到此类的问题,只能恶补。这不,在12月1日凌晨全国统一短信类服务接入代码的调整工作中,我就遇到了此类问题,不得不再次抱起W.Richard Stevens的'TCP详解卷一'啃了啃,回顾一下TCP协议那些事儿。

    做应用层网络程序开发的,手头上都有一把利器:抓包工具,更专业的名词就是协议分析工具,常用的且功能强大的协议分析工具有:TCPDUMP(Windows平台上的叫Windump)、Ethereal等。工作中常常会遇到因应用层程序在协议字段发送和接收解析上不一致而出现'纠纷'问题,这时我们一般采用的在TCP层用协议分析工具抓取该层原始数据包作为'对峙'的证据;还有的就是在客户端与服务器端链接问题上的一些现象也需要到TCP层去分析原因,这就需要对TCP层的基本工作原理有一个清晰的认识。

    首先我们要明确:TCP头部中设置的一系列域都是为了能达到分割、重传、查重、重组、流控、全双工的协议功能而设置的,这里比较重要的字段就是序列号和确认号。由于要达到重传、查重、重组、全双工这些目的,TCP层需要通过序列号和确认号来保证。序列号用来标识发送端传送数据包的顺序,并且指导接收端对多数据包进行顺序重组;发送端传送一个数据包后,它会把这个数据包放入重发队列中,同时启动计时器,如果收到了关于这个包的确认信息,便将此数据包从队列中删除;如果在计时器超时的时候仍然没有收到确认信息,则需要重新发送该数据包。

    TCP层以"三次握手"建立链接而"闻名于世",三次握手的目的:建立链接,为后续的数据流传输奠基,因为TCP是双工的,因此在握手过程需告知彼此数据包发送的起始序列号。

    Client --> 置SYN标志 序列号 = J,确认号 = 0 ----> Server
    Client <-- 置SYN标志 置ACK标志 序列号 = K, 确认号 = J + 1 <-- Server
    Clinet --> 置ACK标志 序列号 = J + 1,确认号 = K + 1 --> Server

    链接建立后,接下来Client端发送的数据包将从J + 1开始,Server端发送的数据包将从K + 1开始,这里要说明的是:建立链接时,Client端宣称自己的初始序列号是J,Server端宣称自己的初始序列号是K,但是建立连接后的数据包却各自中初始序列号+1开始,这是因为SYN请求本身需要占用一个序列号。

    在数据传输阶段,按照常理应用层数据的传输是这样的:(我们假定建立连接阶段Client端最后的确认包中序列号 = 55555, 确认号 = 22222)
    Client --> 置PSH标志,置ACK标志 序列号 = 55555, 确认号 = 22222,数据包长度 = 11 ---> Server 
    Client <-- 置ACK标志,序列号 = 22222, 确认号 = 55566 (=55555 + 11),数据包长度 = 0 <--- Server
    Client <-- 置PSH标志,置ACK标志 序列号 = 22223, 确认号 = 55566,数据包长度 = 22 <--- Server 
    Client --> 置ACK标志,序列号 = 55566, 确认号 = 22244(=22222+22),数据包长度 = 0 ---> Server

    注:PSH标志指示接收端应尽快将数据提交给应用层。从我协议分析的经历来看,在数据传输阶段,几乎所有数据包的发送都置了PSH位;而ACK标志位在数据传输阶段也是一直是置位的。

    但是实际我们在分析过程看到的却都是如下这样的:
    Client --> 置PSH标志,置ACK标志 序列号 = 55555, 确认号 = 22222,数据包长度 = 11 ---> Server 
    Client <-- 置PSH标志,置ACK标志 序列号 = 22222, 确认号 = 55566 (=55555 + 11),数据包长度 = 22 <--- Server
    Client --> 置PSH标志,置ACK标志 序列号 = 55566, 确认号 = 22244 (=22222 + 22),数据包长度 = 33 ---> Server
    Client <-- 置PSH标志,置ACK标志 序列号 = 22244, 确认号 = 55599 (=55566 + 33),数据包长度 = 44 <--- Server

    也就是说:数据接收端将上一个应答和自己待发送的应用层数据组合在一起发送了。TCP的传输原则是尽量减少小分组传输的数量,所以一般默认都开启"带时延的ACK"。一般实现中,时延在200ms。Nagle算法多用来实现"带时延的ACK",它要求一个TCP连接上最多只能有一个未被确认的小分组。在该分组的确认到达之前不能发送其他小分组。也就是说:发送端在发送一个分组后,需等待这个分组的ACK确认后,才可以进行下一个分组的发送。这样一来网络的传输效率被大大降低了。对于大数据块的传输来说,这样很多时候是难以忍受的。另一种拥塞控制策略被引入,那就是TCP的滑动窗口协议,滑动窗口协议是分组发送和分组确认不再同步,发送端可以连续发送n个分组,接收端同样也可以用一个确认包来一起确认这n个分组,通常n = 2。各种OS的TCP协议栈在实现上都是综合了Nagle算法和滑动窗口协议的,TCP层对应用层数据分组大小进行多次判断(一般分组大小都是和MSS做比较的),以在Nagle和滑动窗口协议之间抉择到底选择哪一种控制方式进行发送。"The Linux Network Architecture: Design and Implementation of Network Protocols in the Linux Kernel"一书介绍了Linux在TCP层上的设计和实现,当然最直观的还是去分析Linux源代码了。

    拆除TCP连接过程用一句话表述就是:你关你的发送通道,我关我的发送通道(因为TCP是全双工)。当一方关闭发送通道后,仍可接收另一方发送过来数据,这样的情况就成为"半关闭"。然而多数情况下,"半关闭"使用的很少,而且半关闭需要SOCKET AIP支持在SOCKET上的shutdown(而不是调用close)。

    正常的关闭流程是源于Fin报文的:
    Client --> Fin ACK --> Server
    Client <-- ACK <-- Server
    Client <-- Fin ACK -- Server
    Client --> ACK --> Server
    发送Fin分组的一端会先将发送缓冲中的报文按序发完之后,再发出Fin;所以说Fin又叫做:orderly release。

    异常的关闭流程是源于Rst报文的。一个典型的例子就是当客户端所要链接的服务器端的端口并没有程序在listen,这时服务器端的TCP层会直接发送一个Rst报文,告诉客户端重置连接。Rst报文是无需确认的。客户端在收到Rst后会通知应用层对方异常结束链接(需通过SOCKET API的设置才能得知对方是异常关闭)。
    展开全文
  • TCP半关闭

    千次阅读 2014-01-15 12:06:29
    关闭TCP连接    http://book.51cto.com/art/200902/109775.htm TCP/IP学习笔记(六)   ...理解tcp顺序释放操作和tcp半关闭      http://blog.csdn.net/lllxy/archive/2007/09/12/17

    关闭TCP连接

    TCP/IP学习笔记(六)

    理解tcp顺序释放操作和tcp的半关闭

              http://blog.csdn.net/lllxy/archive/2007/09/12/1782447.aspx



    TCP的半关闭
       TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力,这就是TCP的半关闭。
    客户端发送FIN,另一端发送对这个FIN的ACK报文段。当收到半关闭的一端在完成它的数据传送后,才发送FIN关闭这个方向的连接,客户端再对这个FIN确认,这个连接才彻底关闭。

    回顾TCP协议那些事儿 - [技术前沿]

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明

    http://bigwhite.blogbus.com/logs/11582229.html

    我不是计算机科班出身。记得大学的时候旁听计算机系的网络课,当时计算机系使用教材是"计算机网络--自顶向下方法与Internet特色"的影印版,这本教材与众不同的一个地方就是作者JAMES F.KUROSEKEITH W.ROSS采用了'自顶向下'的编排思路,先从应用层开始,最后讲到物理层。而且这本书在语言上形象生动,通俗易懂。只怪我当初没有一心一意听讲,到现在存在我的脑子中的基本概念居多,深刻理解甚少。以致于工作后遇到此类的问题,只能恶补。这不,在12月1日凌晨全国统一短信类服务接入代码的调整工作中,我就遇到了此类问题,不得不再次抱起W.Richard Stevens的'TCP详解卷一'啃了啃,回顾一下TCP协议那些事儿。

    做应用层网络程序开发的,手头上都有一把利器:抓包工具,更专业的名词就是协议分析工具,常用的且功能强大的协议分析工具有:TCPDUMP(Windows平台上的叫Windump)、Ethereal等。工作中常常会遇到因应用层程序在协议字段发送和接收解析上不一致而出现'纠纷'问题,这时我们一般采用的在TCP层用协议分析工具抓取该层原始数据包作为'对峙'的证据;还有的就是在客户端与服务器端链接问题上的一些现象也需要到TCP层去分析原因,这就需要对TCP层的基本工作原理有一个清晰的认识。

    首先我们要明确:TCP头部中设置的一系列域都是为了能达到分割、重传、查重、重组、流控、全双工的协议功能而设置的,这里比较重要的字段就是序列号和确认号。由于要达到重传、查重、重组、全双工这些目的,TCP层需要通过序列号和确认号来保证。序列号用来标识发送端传送数据包的顺序,并且指导接收端对多数据包进行顺序重组;发送端传送一个数据包后,它会把这个数据包放入重发队列中,同时启动计时器,如果收到了关于这个包的确认信息,便将此数据包从队列中删除;如果在计时器超时的时候仍然没有收到确认信息,则需要重新发送该数据包。

    TCP层以"三次握手"建立链接而"闻名于世",三次握手的目的:建立链接,为后续的数据流传输奠基,因为TCP是双工的,因此在握手过程需告知彼此数据包发送的起始序列号。

    Client --> 置SYN标志 序列号 = J,确认号 = 0 ----> Server
    Client <-- 置SYN标志 置ACK标志 序列号 = K, 确认号 = J + 1 <-- Server
    Clinet --> 置ACK标志 序列号 = J + 1,确认号 = K + 1 --> Server

    链接建立后,接下来Client端发送的数据包将从J + 1开始,Server端发送的数据包将从K + 1开始,这里要说明的是:建立链接时,Client端宣称自己的初始序列号是J,Server端宣称自己的初始序列号是K,但是建立连接后的数据包却各自中初始序列号+1开始,这是因为SYN请求本身需要占用一个序列号。

    在数据传输阶段,按照常理应用层数据的传输是这样的:(我们假定建立连接阶段Client端最后的确认包中序列号 = 55555, 确认号 = 22222)
    Client --> 置PSH标志,置ACK标志 序列号 = 55555, 确认号 = 22222,数据包长度 = 11 ---> Server 
    Client <-- 置ACK标志,序列号 = 22222, 确认号 = 55566 (=55555 + 11),数据包长度 = 0 <--- Server
    Client <-- 置PSH标志,置ACK标志 序列号 = 22223, 确认号 = 55566,数据包长度 = 22 <--- Server 
    Client --> 置ACK标志,序列号 = 55566, 确认号 = 22244(=22222+22),数据包长度 = 0 ---> Server

    注:PSH标志指示接收端应尽快将数据提交给应用层。从我协议分析的经历来看,在数据传输阶段,几乎所有数据包的发送都置了PSH位;而ACK标志位在数据传输阶段也是一直是置位的。

    但是实际我们在分析过程看到的却都是如下这样的:
    Client --> 置PSH标志,置ACK标志 序列号 = 55555, 确认号 = 22222,数据包长度 = 11 ---> Server 
    Client <-- 置PSH标志,置ACK标志 序列号 = 22222, 确认号 = 55566 (=55555 + 11),数据包长度 = 22 <--- Server
    Client --> 置PSH标志,置ACK标志 序列号 = 55566, 确认号 = 22244 (=22222 + 22),数据包长度 = 33 ---> Server
    Client <-- 置PSH标志,置ACK标志 序列号 = 22244, 确认号 = 55599 (=55566 + 33),数据包长度 = 44 <--- Server

    也就是说:数据接收端将上一个应答和自己待发送的应用层数据组合在一起发送了。TCP的传输原则是尽量减少小分组传输的数量,所以一般默认都开启"带时延的ACK"。一般实现中,时延在200ms。Nagle算法多用来实现"带时延的ACK",它要求一个TCP连接上最多只能有一个未被确认的小分组。在该分组的确认到达之前不能发送其他小分组。也就是说:发送端在发送一个分组后,需等待这个分组的ACK确认后,才可以进行下一个分组的发送。这样一来网络的传输效率被大大降低了。对于大数据块的传输来说,这样很多时候是难以忍受的。另一种拥塞控制策略被引入,那就是TCP的滑动窗口协议,滑动窗口协议是分组发送和分组确认不再同步,发送端可以连续发送n个分组,接收端同样也可以用一个确认包来一起确认这n个分组,通常n = 2。各种OS的TCP协议栈在实现上都是综合了Nagle算法和滑动窗口协议的,TCP层对应用层数据分组大小进行多次判断(一般分组大小都是和MSS做比较的),以在Nagle和滑动窗口协议之间抉择到底选择哪一种控制方式进行发送。"The Linux Network Architecture: Design and Implementation of Network Protocols in the Linux Kernel"一书介绍了Linux在TCP层上的设计和实现,当然最直观的还是去分析Linux源代码了。

    拆除TCP连接过程用一句话表述就是:你关你的发送通道,我关我的发送通道(因为TCP是全双工)。当一方关闭发送通道后,仍可接收另一方发送过来数据,这样的情况就成为"半关闭"。然而多数情况下,"半关闭"使用的很少,而且半关闭需要SOCKET AIP支持在SOCKET上的shutdown(而不是调用close)。

    正常的关闭流程是源于Fin报文的:
    Client --> Fin ACK --> Server
    Client <-- ACK <-- Server
    Client <-- Fin ACK -- Server
    Client --> ACK --> Server
    发送Fin分组的一端会先将发送缓冲中的报文按序发完之后,再发出Fin;所以说Fin又叫做:orderly release。

    异常的关闭流程是源于Rst报文的。一个典型的例子就是当客户端所要链接的服务器端的端口并没有程序在listen,这时服务器端的TCP层会直接发送一个Rst报文,告诉客户端重置连接。Rst报文是无需确认的。客户端在收到Rst后会通知应用层对方异常结束链接(需通过SOCKET API的设置才能得知对方是异常关闭)。

    展开全文
  • tcp 半关闭

    2017-02-15 16:44:58
    Shutdown的调用 ... 在关闭socket的时候,可以有两种方式closesocket和shutdown,这两个函数的区别在什么地方呢? #include  #include   intshutdown(int s, inthow)  int shutdown(SOCKET s,inthow)
    Shutdown的调用
           在关闭socket的时候,可以有两种方式closesocket和shutdown,这两个函数的区别在什么地方呢?
    #include<sys/socket.h>            
    #include<winsock.h>              
             intshutdown(int s, inthow)          
    int shutdown(SOCKET s,inthow)   
     
    how
    操作
    数字
    POSIX
    Winsock
    0
    SHUT_RD
    SD_RECEIVE
    关闭连接接收方
    1
    SHUT_WR
    SD_SEND
    关闭连接的发送方
    2
    SHUT_RDWR
    SD_BOTH
    关闭双方
                                            Shutdown参数how值介绍
    说明:
    1.       shutdown根本没有关闭socket,任何与socket关联的资源直到调用closesocket才释放。
    2.       TCP连接的socket是全双工的,也就是说它可以发送和接收数据,但是一个方向上的数据流动和另一个方向上的数据流动是不相关的,shutdown函数的功能也就是体现在这里,它通过设置how选择关闭哪条数据通道(发送通道和接收通道),如果关闭了发送通道,那么这个socket其实还可以通过接收通道接受数据.
    3.       当通过以how=1的方式调用shutdown,就可以保证对方收到一个EOF,而不管其他的进程是否已经打开了套接字,而调用close或closesocket就不能保证,因为直到套接字的引用计数减为0时才会发送FIN消息给对方,也就是说,直到所有的进程都关闭了套接字。
    例子说明
     客户端(192.168.1.122):客户端连接上服务器后向服务器发送两条数据(数据发送间隔为2秒),等待两秒后立即调用shutdown关闭发送数据通道或者closesocket,然后客户端在一个while循环中等待接受服务器发送回来的数据.
     服务器(192.168.1.112):接受到客户端发送的数据后,休眠4秒后,把得到的数据发送会客户端
     
    1.       shutdown关闭发送数据通道后,通过抓包程序获取的tcp处理过程。
       
                    Shutdown关闭socket时,tcp的状态处理过程.
    对上面的处理过程进行分析:
    l         前面的三条记录是tcp的三次握手.
    l         第四条记录就是客户端第一次向服务器发送数据
    l         第五条记录是服务器的确认信息
    l         第六条记录就是客户端间隔2秒后第二次向服务器发送数据
    l         第七条记录时服务器的确认信息
    l         第八条记录是在等待2秒后,调用了shutdown,客户端向服务器发送了FIN标志
    l         第九条记录时服务器的确认信息
    l         第十条记录是服务器接收到客户端的一条记录后休眠4秒,发回给客户端
    l         第十一条记录是客户端的确认
    l         第十二条记录是服务器接受到客户端的第二条数据后休眠4秒,发回给客户端
    l         第十三条记录是客户端的确认
    l         第十四条记录是服务器发送完tcp对列中的数据后,向客户端发送FIN标志
    l         第十五条记录时客户端对FIN标志的确认
     
    2.       closesocket关闭socket,通过抓包程序获取的tcp处理过程
    Closesocket关闭socket时,tcp的状态处理过程
     
     
    对上面的处理过程进行分析:
    l         前面的三条记录是tcp的三次握手.
    l         第四条记录就是客户端第一次向服务器发送数据
    l         第五条记录是服务器的确认信息
    l         第六条记录就是客户端间隔2秒后第二次向服务器发送数据
    l         第七条记录时服务器的确认信息
    l         第八条记录是在等待2秒后,调用了shutdown,客户端向服务器发送了FIN标志
    l         第九条记录时服务器的确认信息
    l         第十条记录是服务器接收到客户端的一条记录后休眠4秒,发回给客户端
    l         第十一条记录是由于客户端已经通过closesocket关闭了连接,连接已经不存在,因此客户端向服务器发送了RST标志
    总结

           为了保证在连接撤销之前,保证双方都能接收到对等方的所有数据,在调用closesocket之前,先调用shutdown关闭发送数据通道


    单工就相当于二极管,数据只能从一端流向另一端。全双工就相当于一个完整的电路,数据可以从A流到B,也可以从B流动会到A,他们甚至还可以同时进行。
    在计算机连接的另一端发送FIN包时socket不会自动发送FIN包。它为被标识为不可读但可写的状态。 
    把socket标识为可写不可读的状态就意味着它并没有断开,只是认为对方告诉自己将不再发送数据了而已。如果是Socket程序,就需要手动调用方法去关闭这个连接,否则它会一直工作。有些恶意攻击的程序就利用这个机制让没有限制半开连接的服务器打开大量的半开连接,使对方的连接数消耗殆尽。所以很多操作系统都自带了半开连接数的使用限制。

    展开全文
  • TCP链接中A向B发送 FIN 请求关闭,另一端B回应ACK之后,并没有立即发送 FIN 给A,A方处于半关闭状态。 此时A可以接收B发送的数据,但是A已经不能再向B发送数据。 半连接: 发生在TCP三次握手中 如果A向B发起...

    半关闭:

    • 当TCP链接中A向B发送 FIN 请求关闭,另一端B回应ACK之后,并没有立即发送 FIN 给A,A方处于半关闭状态。
    • 此时A可以接收B发送的数据,但是A已经不能再向B发送数据。

    半连接:

    发生在TCP三次握手中 
    如果A向B发起链接,B也按照正常情况响应了,但是A不进行三次握手,这就是半连接。 
    半连接攻击:半连接,会造成B分配的内存资源就一直这么耗着,直到资源耗尽。(SYN攻击)

    半打开:

    如果一方关闭或者异常关闭(断电,断网),而另一方并不知情,这样的链接称之为半打开。处于半打开的连接,如果双方不进行数据通信,是发现不了问题的,只有在通信是才真正的察觉到这个连接已经处于半打开状态,如果双方不传输数据的话,仍处于连接状态的一方就不会检测另外一方已经出现异常

    解决方法:

    如何解决半打开问题,引入心跳机制就可以察觉半打开。

    如果需要发数据的话,这边收到之后 其实发现这个连接并不存在了,就会回复RST包告知,这个时候就需要重新建立连接了!

    展开全文
  • 半关闭输出时:对应TCP四次挥手的 FIN_WAIT_2状态 半打开: 如果一方异常关闭(断网,断电),而另一方并不知情。处于半打开的状态,如果双方不进行数据通信,是无法发现问题的。可以引入心跳机制,以检测半...
  • TCP半关闭状态

    千次阅读 2017-06-26 15:19:38
    TCP链接中A发送FIN请求关闭,B端回应ACK后(A端进入FIN_WAIT_2状态),B没有立即发送FIN给A时,A方处在链接状态,此时A可以接收B发送的数据,但是A已不能再向B发送数据。  从程序的角度,可以使用API来控制...
  • 下面我们介绍典型的TCP连接的建立与关闭过程(不包括任何数据传输) 一、TCP连接的建立(三次握手) TCP连接的建立分为3步: 1.主动开启者(通常称为客户端)发送一个SYN报文段(即一个在TCP头部的SYN位字段置位...
  • 1.memset(void *s,int ch,size_t n) 函数解释:将s中当前位置后面的n个字节 (typedef unsigned int size_t )用 ch 替换并返回 s 。 memset:作用是在一段内存块中填充某个给定的值,它是对较大的结构体或数组...
  • 关闭TCP连接 http://book.51cto.com/art/200902/109775.htm TCP/IP学习笔记(六) ...理解tcp顺序释放操作和tcp半关闭 http://blog.csdn.net/lllxy/archive/2007/09/...
  • TCP半关闭

    2019-04-07 17:42:51
    半关闭是什么 TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这就是所谓 的半关闭。 什么时候处于半关闭 如图所示当四次挥手处于被动关闭的一方在收到主动关闭方的FIN时,进入CLOSE_WAIT状态...
  • TCP三次握手中,A向B发起连接请求,B正常响应,但是A不进行三次握手,这样的情况为连接。 连接攻击:连接,会造成B分配的内存资源就一直这么耗着,直到资源耗尽。(SYN攻击) 打开: 如果通信双方中,有一方...
  • tcp支持半关闭

    2019-08-01 15:13:34
    tcp断开通过四次握手来实现,四次握手见https://blog.csdn.net/a1009563517/article/details/49299819。 那么断开需要客户端和服务端都向对方发送Fin报文,...半关闭状态下是允许未发送Fin的一端继续发送报文给已关...
  • 18.5 TCP半关闭

    2020-02-24 11:02:33
    18.5 TCP半关闭 TCP提供了连接的一端的结束它的发送后还能接收另一端数据的能力。 这就是所谓的半关闭 print(socket.SHUT_RDWR) print(socket.SHUT_RD) print(socket.SHUT_WR) 2 0 1 0是READ,1是WRITE,2是...
  • TCP半关闭

    千次阅读 2014-03-26 16:47:10
    何为半关闭TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这就是所谓的半关闭。 怎么使用半关闭? 为了使用这个特性,编程接口必须为应用程序提供一种方式来说明“我已经完成了数据 传送...
  • TCP半关闭状态

    千次阅读 2019-03-17 11:32:03
    为什么TCP要支持半关闭状态这种特性? 由于在全关闭的状态下,当服务器端的数据发送完毕要关闭连接的时候,这时客户端会接收到服务器端的请求,但由于使用全关闭状态,则客户端向服务器端发送的断开连接确认请求将...
  • 基于TCP半关闭

    千次阅读 2016-12-22 07:17:07
    基于TCP半关闭 TCP练级的半关闭简而言之就是”关闭连接的一半”(只可以传递或接收数据)   套接字和流 两台主机通过套接字建立连接后进入可交换数据的状态(流形参的状态),即将建立套接字后可交换数据的状态看做一...
  • 18.5 TCP半关闭 T C P提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。这就是所谓的半关闭。正如我们早些时候提到的只有很少的应用程序使用它。 为了使用这个特性,编程接口必须为应用程序提供一...
  • TCP半关闭与CLOSE_WAIT

    2018-05-05 23:32:00
    这由TCP半关闭(half-close)造成的。既然一个TCP连接是全双工(即数据在两个方向上能同时传递,可理解为两个方向相反的独立通道),因此每个方向必须单独地进行关闭。 这原则就是当一方完成它的数据发送任务后...
  • gen_tcp连接半关闭问题

    千次阅读 2013-06-07 13:36:00
    很久之前我发在javaeye论坛上,预防丢了抄过来: ...当tcp对端调用shutdown(RD/WR) 时候, 宿主进程默认将收到{tcp_closed, Socket}消息, 如果这个行为不是你想要的,那么请看: shutdown(Socket,
  • 深入浅出TCP半关闭与CLOSE_WAIT2013-09-13 0个评论 作者:weizhulinux收藏我要投稿深入浅出TCP半关闭与CLOSE_WAIT 终止一个连接要经过4次握手。这由TCP半关闭(half-close)造成的。既然一个TCP连接是全双工...
  • TCP之半打开和半关闭

    2017-09-03 16:45:00
     另外从linux实现的角度来说,因为linux内部有个半连接队列,TCP半开连接是指发送了TCP连接请求,等待对方应答的状态。此时连接并没有完全建立起来,双方还无法进行通信交互的状态,此时就称为半连接。由于一个完整...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 551
精华内容 220
关键字:

tcp半关闭