精华内容
下载资源
问答
  • TCP状态转移

    2019-09-10 21:02:44
    TCP状态转移 在前一篇文章已经介绍了TCP协议的三次握手和四次挥手。总的来说,TCP通信过程包括三个步骤:建立TCP连接(三次握手)、数据传输、终止TCP连接(四次挥手)。但是在这个通信过程中,有非常复杂的状态问题...

    TCP状态转移

    在前一篇文章已经介绍了TCP协议的三次握手和四次挥手。总的来说,TCP通信过程包括三个步骤:建立TCP连接(三次握手)、数据传输、终止TCP连接(四次挥手)。但是在这个通信过程中,有非常复杂的状态问题,下面就来了解一下进行TCP协议通信时候的状态转移。

    TCP协议根据连接时接收到报文的不同类型,采取相应动作也不同,还要处理各个状态的关系,如当收到握手报文时候、超时的时候、用户主动关闭的时候等都需要不一样的状态去采取不一样的处理。在LwIP中,为了实现TCP协议的状态描述,定义了11种连接时候的状态:

    static const char *const tcp_state_str[] = {
      "CLOSED",     //关闭状态(无连接)
      "LISTEN",     //监听状态
      "SYN_SENT",   //已发起请求连接(等待确认)
      "SYN_RCVD",   //已收到请求连接
      "ESTABLISHED",//稳定连接状态
      "FIN_WAIT_1", //单向请求终止连接状态
      "FIN_WAIT_2", //对方已应答请求终止连接
      "CLOSE_WAIT", //等待终止连接
      "CLOSING",    //两端同时关闭  
      "LAST_ACK",   //服务器等待对方接受关闭
      "TIME_WAIT"   //关闭成功(2MSL等待状态)
    };
    
    • LISTEN:表示监听状态。服务器调用了listen函数进入监听状态,客户端可以开始进行连接了。
    • SYN_SENT:表示客户端已经发送了SYN报文请求连接(同时在等待服务器的确认)。当客户端调用connect函数发起连接时,首先发SYN给服务端,然后自己进入SYN_SENT状态,并等待服务端发送ACK+SYN报文(握手应答报文)进行确认。
    • SYN_RCVD:在每一个 TCP 连接建立时,都要进行三次握手,这个状态表示服务器接收到客户端发来的同步报文段(第一次握手),并且向客户端发送了确认同步报文段(第二次握手)之后的状态,在这个状态时,其实连接已经经历了两次握手。
    • ESTABLISHED:这个状态是处于稳定连接状态,建立连接的TCP协议两端的主机都是处于这个状态,它们相互知道彼此的窗口大小、序列号、最大报文段等信息。
    • FIN_WAIT_1FIN_WAIT_2:处于这个状态一般都是客户端主机单向请求终止连接,然后主机等待服务器的回应,而如果服务器产生应答,则主机状态转移为FIN_WAIT_2,此时<客户端 -> 服务器 >方向上的TCP连接就断开,但是<服务器 -> 客户端>方向上的连接还是存在的。此处有一个注意的地方:如果主机处于FIN_WAIT_2状态,说明主机已经发出了FIN报文段,并且服务器也已对它进行确认,除非客户端是在实行半关闭状态,否则将等待服务器主机的应用层处理关闭连接,因为服务器已经意识到它已收到FIN报文段,它需要发一个 FIN 来关闭<服务器 -> 客户端>方向上的连接。这样客户端这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。如果是网络不好或者是服务器不发送FIN报文段的时候,这意味着客户端这端可能永远保持这个FIN_WAIT_2状态,从而无法 进入CLOSE_WAIT状态,并一直占用这个端口连接或者socket,在嵌入式中,如果存在多个这种状态的话,则这很可能导致内存耗尽。
    • CLOSE_WAIT: 在收到客户端主动断开连接的 FIN 报文段(第一次挥手)后,服务器返回给客户端确认报文段(第二次挥手)后的状态。
    • TIME_WAIT状态:TIME_WAIT状态也称为 2MSL等待状态

    具体见下图:

    1. 红色虚线:表示服务器的状态转移。
    2. 黑色实线:表示客户端的状态转移。
      TCP协议状态转移

    RST

    顺便再提一点不太常见的TCP协议状态转移,主要是针对服务器端的(绿色那条):

    1. 服务器在收到SYN握手报文后,再收到了客户端的RST报文,那么它会重新进入监听状态,再重新等待连接。

    一般说来,无论何时一个报文段发往基准的连接出现错误, TCP都会发出一个复位报文段(这里提到的基准的连接是指由目的 IP地址、目的端口号、源 IP地址和源端口号都是已知的连接。

    此外产生复位的另一种常见情况是当连接请求到达时,目的端口并没有在监听中,当一个数据报到达目的端口时,它将产生一个ICMP端口不可达的信息,同时TCP协议将进行复位,当然啦,在lwip中这些ICMP端口不可达报文都会被丢弃的,也不用管那么多。

    TIME_WAIT

    第一次看这个转移图的时候,可能很多人都有疑惑,为什么要有一个 TIME_WAIT 状态?为什么不能直接到达 CLOSED 状态?

    每个具体TCP连接的实现必须选择一个TCP报文段最大生存时间MSL(Maximum Segment Lifetime),就如IP数据报中的TTL字段表示报文在网络中生存的时间一样。MSL是任何报文段被丢弃前在网络内的最长时间,这个时间是有限的,为什么需要等待呢?我们知道IP数据报是不可靠的,而TCP报文段是封装在IP数据报中,TCP协议必须保证发出的ACK报文段是正确被对方接收, 因此处于该状态的主机必须在这个状态停留最长时间为2倍的MSL,以防最后这个ACK丢失,因为TCP协议必须保证数据能准确送达目的地。

    假设没有 TIME_WAIT 这种状态。现实中,网络环境不是理想的。在数据包传输的过程中,难免会有一些延时啊、丢包啊的情况发生。如果在客户端的最后一个确认报文段发出去之后,由于某种原因,没有到达服务端,服务端在超时后,就会向客户端重新发一个 FIN 报文段,请求重传这个已经丢失的确认报文段。但由于在客户端,连接实际上已经断开,端口已经关闭。那么在客户端收到这个报文段后,会向服务端发送一个 RST 报文段请求重连(这也是为什么我要在前面讲解RST的原因 ),而此时服务器收到这个 RST报文段后,会认为是错误的,因为在服务器看来都没断开连接,它所期望收到的是确认报文段。所以这个时候客户端是不允许直接CLOSE关闭了事的,因此它需要等待服务器确认了,再CLOSE

    再假设一下:如果没有 TIME_WAIT 这种状态,客户端在关闭连接后,再次成功建立新的连接,客户端任然可能会收到服务器的最后一个确认报文段,但是由于序号不同(重新建立连接时的序号是随机的,这点很重要,要记住),客户端会要求服务端重传数据包,这样,连接就必然会混乱出错。而在 TIME_WAIT 这种状态等待一段时间是为了让本次连接的时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的报文。

    TIME_WAIT 状态的等待时间一般是 2MAL ,并且客户端连接的端口没有释放,这样,让前一个连接的报文段有足够的时间被处理或者丢弃,也就不会出现这个问题。

    这才是TCP协议优雅且可靠的终止连接方式啊!太强大了,我得膜拜一下~

    展开全文
  • tcp状态转移

    千次阅读 2017-08-13 16:41:05
    TCP状态转移图一个正常连接和断开过程客户端和服务器端的状态转移如下: 其中TIME_WAIT 状态是在服务端发送FIN后,客户回复ACK后,客户端需要等待2MSL时间(报文最大生存时间): 1. 此时若是客户端回复的ACK因为网络...

    TCP状态转移图

    一个正常连接和断开过程客户端和服务器端的状态转移如下:

    其中TIME_WAIT 状态是在服务端发送FIN,客户回复ACK后,客户端需要等待2MSL时间(报文最大生存时间):
    1. 此时若是客户端回复的ACK因为网络的原因,服务端没有收到,服务端要重发FIN,客户端此时处于TIME_WAIT状态,可以继续发送ACK。 总体来说TIME_WAIT状态时为了保证最后一个ACK因丢失,而等待重发的时间。
    2. 保证残留网络报不会被新连接接收而产生数据错乱。由于自己上一次发送的数据包可能还残留在网络中,等待2MSL时间可以保证所有残留的网络报在自己关闭前都已经超时。

    服务器也是可以主动关闭的,状态会与上图刚好相反。

    各中间报文发送失败

    1. 第一次握手失败,等待一定时间重新发送。
    2. TCP第三次握手失败(包含第二次)
      第二个syn报文发送失败或第三个ack失败,服务器过段时间没收到ack,会重传syn+ack,客户端收到后再发ack。另一种方式为:当失败时服务器并不会重传ack报文,而是直接发送RST报文段,进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。
    3. 前3次挥手失败
      主动关闭方发送的FIN,被动发送端发送的FIN和ACK,只要其中有一个发送失败,主动方都会在一定时间内(60s)直接进入CLOSED状态。如果是第二个或第三个失败,被动方是处于LAST_ACK状态的,一定时间内再次发送FIN,如果顺利会正常关闭,否则被动方也会在一定时间内关闭。
    4. 第四次挥手失败
      假如这个时候,主动方还是处于TIME_WAIT状态(也就是TIME_WAIT持续的时间在2MSL内),主动方收到这个FIN包后向被动方发送了一个ACK包,被动方收到这个ACK包之后进入CLOSD状态。
      假如这个时候,主动方已经从TIME_WAIT状态变成了CLOSED状态 ,收到这个FIN包后,认为这是一个错误的连接,向被动方发送一个RST包,当被动方收到这个RST包,进入CLOSED状态。

    tcp关闭状态详解
    TCP连接的状态详解以及故障排查

    展开全文
  • 读懂TCP状态转移

    2019-02-23 15:15:48
    读懂TCP状态转移过程,对理解网络编程颇有帮助,本文将对TCP状态转移过程进行介绍,但各状态(总共11个)含义不在本文介绍的范围,请参考文末的书目列表。 TCP状态转换图(state transition diagram) 1. 建立...

    本文转自:https://www.cnblogs.com/figo-cui/p/5137993.html

    读懂TCP状态转移过程,对理解网络编程颇有帮助,本文将对TCP状态转移过程进行介绍,但各状态(总共11个)含义不在本文介绍的范围,请参考文末的书目列表。

    TCP状态转换图(state transition diagram)

    状态转换图

    1. 建立连接(three-way hand shake)

    • 主动打开(passive open):服务器必须准备好接受外来的连接,通常通过socket、bind和listen完成。
    • 被动打开(active open):客户端通过connect发起主动打开。

    插句话,该文介绍的性能分析工具(sar -n TCP,ETCP 1)命令可以对主动打开和被动打开的数目进行统计,在一定程度上可以反应服务器的繁忙程度。

    下图给出客户端与服务器的三次握手过程:

    三次握手过程

    1. 服务器准备好接受外来连接,通常通过socket、bind和listen完成。(服务器:CLOSED->LISTEN)
    2. 客户端通过connect连接服务器,客户端TCP将发送一个SYN包,告诉服务器客户端将在待建立连接发送数据的初始序列号。(客户端:CLOSED->SYN_SENT)
    3. 服务器端必须ACK客户端SYN,同时发送一个SYN,告诉客户端,服务器将在待建立连接发送数据的初始序列号。(服务器:SYN_RCVD)
    4. 客户端必须ACK服务器SYN。(客户端:SYN_SENT->ESTABLISHED)
    5. 服务器接收到客户端ACK。(服务器:SYN_RECV->ESTABLISHED)

    下图给出三次握手对应的状态转移图:

    状态转移图

    2. 建立连接(同时打开simultaneous open)

    参考《TCP/IP详解》卷一第18章18.8节。这种情况发生在两端几乎同时发送SYN并且这两个SYN在网络中交错的情形。这种情况可能发生,但是非常罕见。

    例如,主机A的应用程序使用本地端口7777,并与主机B的端口8888执行主动打开。主机B的应用程序使用本地端口8888,并与主机A的端口7777执行主动打开。

    下图给出同时打开过程:

    同时打开过程

    下图给出同时打开的状态转移图:

    状态转换图

    说明:从目前个人经验来看,这种场景没有遇到过,但这是完整理解TCP状态转移必须的一部分。但《TCP/IP详解》卷一第18章18.8节中支出,许多伯克利版的TCP实现都不能正确地支持打开。

    3. 建立连接失败(1)

    考虑场景:客户端尚未接收到服务器ACK+SYN,异常退出(崩溃退出)。这时,当客户端接收到服务器的ACK+SYN时,客户端回复RST(reset)。此时服务器处于SYN_RCVD状态,当接收到客户端RST时,则从SYN_RCVD转移到LISTEN状态。

    具体过程:

    1. 服务器准备好接受外来连接,通常通过socket、bind和listen完成。(服务器:CLOSED->LISTEN)
    2. 客户端通过connect连接服务器,客户端TCP将发送一个SYN包,告诉服务器,客户端将在待建立连接发送数据的初始序列号。然后客户端异常退出。(客户端:CLOSED->SYN_SENT,然后突然crash,则退出SYN_SENT)
    3. 服务器端ACK客户端SYN,同时发送一个SYN,告诉客户端,服务器将在待建立连接发送数据的初始序列号。(服务器:SYN_RCVD)
    4. 客户端找不到服务器ACK+SYN对应的SYN_SENT状态的socket,则响应RST。(服务器:SYN_RCVD->LISTEN)

    下图给出建立连接失败的状态转移图:

    状态转换图

    4. 建立连接失败(2)

    考虑场景1:服务器的进程异常退出,客户端不知道。那么客户端发送SYN后,服务器端响应RST,则客户端建立连接失败。

    考虑场景2:服务器机器关闭,导致服务器IP不可达。那么客户端发送SYN后,超时重发,超过重试次数,最终TIMEOUT,则客户端建立连接失败。

    具体过程:

    1. 假设服务器进程退出。(服务器:LISTEN->CLOSED)
    2. 客户端通过connect连接服务器,客户端TCP将发送一个SYN包,告诉服务器,客户将在待建立连接发送数据的初始序列号。(客户端:CLOSED->SYN_SENT)
    3. 服务器端收到客户端SYN,响应RST(服务器:CLOSED)
    4. 客户收到RST。(客户端:SYN_SENT->CLOSED)

    下图给出建立连接失败的状态转移图:

    状态转换图

    5. 断开连接(四次挥手)

    • 主动关闭(active close):某个应用程序首先调用close,发送一个FIN包。
    • 被动关闭(passive close):接收到FIN的对端执行被动关闭。

    下图给出客户端与服务器的四次挥手过程:

    四次挥手

    1. 某个应用程序首先调用close,该端发送一个FIN包,表示数据发送完毕,该应用程序再无更多数据发送给对端。(例如HTTP服务器发送Reponse数据给client后,再无多余数据发送,则Server可以执行主动关闭)(主动端:ESTABLISHED->FIN_WAIT_1)
    2. 接收到FIN的对端执行被动关闭。首先ACK这个收到的FIN包。该FIN包的接收也作为一个文件结束符(EOF)传递给应用程序(放在已排队等候该应用进程接收的任何其他数据之后),因为FIN包意味着接收端应用进程在相应的连接上再无额外数据可接收。(被动端:ESTABLISHED->CLOSE_WAIT,主动端:FIN_WAIT_1->FIN_WAIT_2)
    3. 一段时间后,接收到这个EOF的应用进程将调用close关闭socket。这导致它的TCP也发送一个FIN包。(被动端:CLOSE_WAIT->LAST_WAIT)
    4. 接收这个最终FIN的执行主动关闭的那一端ACK这个FIN。(被动端:LAST_WAIT->CLOSED,主动端:FIN_WAIT_2->TIME_WAIT(2MSL之后,TIME_WAIT->CLOSED))

    下图给出四次挥手的状态转移图:

    状态转换图

    6. 断开连接(同时关闭simultaneous close)

    参考《TCP/IP详解》卷一第18章18.9节。我们在前面讨论了一方(通常但不总是客户方)发送第一个FIN执行主动关闭。双方都执行主动关闭也是可能的,TCP协议也允许这样的同时关闭(simultaneous close)。

    下图给出同时关闭过程:

    同时打开过程

    下图给出同时关闭的状态转移图:

    状态转换图

    7. 断开连接(在FIN_WAIT_1状态中,接收FIN+ACK)

    考虑场景:被动关闭端收到FIN包后,直接发送FIN+ACK,则主动关闭方则从FIN_WAIT_1跳过FIN_WAIT_2,直接进入TIME_WAIT。

    给出具体流程:

    1. 某个应用程序首先调用close,该端发送一个FIN包,表示数据发送完毕,该应用程序再无更多数据发送给对端。(例如HTTP服务器发送Reponse数据给client后,再无多余数据发送,则Server可以执行主动关闭)(主动端:ESTABLISHED->FIN_WAIT_1)
    2. 接受到FIN的对端执行被动关闭。收到FIN包之后,被动端调用close关闭socket,则FIN+ACK同时发给主动端。(被动端:ESTABLISHED->CLOSE_WAIT->LAST_ACK,主动端:FIN_WAIT_1->TIME_WAIT)
    3. 接收这个最终FIN的执行主动关闭的那一端ACK这个FIN。(被动端:LAST_WAIT->CLOSED,主动端:FIN_WAIT_1->TIME_WAIT(2MSL之后,TIME_WAIT->CLOSED))

    下图给出同时关闭的状态转移图:

    状态转换图

    参考:

    1. 中文版《UNIX网络编程》第一卷第2章
    2. 中文版《TCP/IP详解》卷一第18章

    错误说明:

    1. 中文版《UNIX网络编程》第一卷(第三版)(第一次印刷版)图2.4有个错误,服务器从LISTEN转移到SYN_RCVD时,条件应该是“接收:SYN;发送:SYN,ACK”,而不是“接收:RST;发送:SYN,ACK”。这一点可以从英文原本的配图看到。(注:2015年8月第二次印刷已经修订这个错误)
    2. 我也认为,书中的TCP状态转移图中,SYN_RCVD转移到LISTEN的条件应该是服务器状态,而非客户端状态

    纠错

    关于作者:

    限于本人对某些技术点的理解程度(虽然也查了很多资料),可能某些地方表达的不太准确,敬请指教,联系方式为pengfeicui@yeah.net。

    展开全文
  • TCP状态转移详解

    2018-06-05 18:00:25
    在看TCP状态转移图之前,我们先来看一下三次握手和四次挥手画了一个比较简陋的图1、建立连接协议(三次握手) (1)客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。 (2) 服务器端回应...

    在看TCP状态转移图之前,我们先来看一下三次握手和四次挥手

    画了一个比较简陋的图

    1、建立连接协议(三次握手) 
    1)客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。 
    2) 服务器端回应客户端的,这是三次握手中的第2个报文,这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应;同时又标志SYN给客户端,询问客户端是否准备好进行数据通讯。 
    3) 客户必须再次回应服务段一个ACK报文,这是报文段3。

    三次握手


    2、连接终止协议(四次握手) 
      由于TCP连接是全双工的,因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动,一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。 
    1) TCP客户端发送一个FIN,用来关闭客户到服务器的数据传送(报文段4)。 
    2) 服务器收到这个FIN,它发回一个ACK,确认序号为收到的序号加1(报文段5)。和SYN一样,一个FIN将占用一个序号。 
    3) 服务器关闭客户端的连接,发送一个FIN给客户端(报文段6)。 
    4) 客户段发回ACK报文确认,并将确认序号设置为收到序号加1(报文段7)。


    四次挥手



    状态转移图



    CLOSED: 这个没什么好说的了,表示初始状态。

    LISTEN: 这个也是非常容易理解的一个状态,表示服务器端的某个SOCKET处于监听状态,可以接受连接了。

    SYN_RCVD: 这个状态表示接受到了SYN报文,在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态,很短暂,基本 上用netstat你是很难看到这种状态的,除非你特意写了一个客户端测试程序,故意将三次TCP握手过程中最后一个ACK报文不予发送。因此这种状态 时,当收到客户端的ACK报文后,它会进入到ESTABLISHED状态。

    SYN_SENT: 这个状态与SYN_RCVD遥想呼应,当客户端SOCKET执行CONNECT连接时,它首先发送SYN报文,因此也随即它会进入到了SYN_SENT状 态,并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。

    ESTABLISHED: 这个容易理解了,表示连接已经建立了。

    FIN_WAIT_1(重要): 这个状态要好好解释一下,其实FIN_WAIT_1FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别 是:FIN_WAIT_1状态实际上是当SOCKETESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即 进入到FIN_WAIT_1状态。而当对方回应ACK报文后,则进入到FIN_WAIT_2状态,当然在实际的正常情况下,无论对方何种情况下,都应该马 上回应ACK报文,所以FIN_WAIT_1状态一般是比较难见到的,而FIN_WAIT_2状态还有时常常可以用netstat看到。

    FIN_WAIT_2(重要): 上面已经详细解释了这种状态,实际上FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你,稍后再关闭连接。

    TIME_WAIT(重要: 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带 FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。

    CLOSING: 这种状态比较特殊,实际情况中应该是很少见,属于一种比较罕见的例外状态。正常情况下,当你发送FIN报文后,按理来说是应该先收到(或同时收到)对方的 ACK报文,再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什 么情况下会出现此种情况呢?其实细想一下,也不难得出结论:那就是如果双方几乎在同时close一个SOCKET的话,那么就出现了双方同时发送FIN报 文的情况,也即会出现CLOSING状态,表示双方都正在关闭SOCKET连接。

    CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文给对 方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。

    LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。

     



    展开全文
  • 详解TCP状态转移

    千次阅读 2018-02-27 15:27:24
    根据TCP状态转移过程图,可进行一步一步分析。 一般而言,TCP连接是由客户端发起,并通过三次握手建立连接(特殊情况是所谓同时打开)的。 TCP关闭过程相对复杂一些,可能是客户端执行主动关闭;也可能是服务器...
  • 下图为完整的TCP状态转移图,它描绘了所有的TCP状态以及可能的状态转换。 图中的粗虚线表示典型的服务器端连接的状态转移;粗实线表示典型的客户端连接的状态转移。CLOSED是一个假想的起始点,并不是一个实际状态。...
  • 近日在对学员们讲解TCP状态转移时,看到他们一脸懵逼的表情,甚是心疼。 昨日灵感来了,想起《三体》里地球三体组织和三体时间的通信正适合用来描述TCP状态转移,并且询问了手里的几个学员是否看过《三体》,令人...
  • 前面介绍了计算机网络的基础知识,今天我们来看一下TCP状态转移的“三次握手”和“四次挥手”。状态转移指的是TCP的连接建立到关闭整个过程中通信两端状态的变化。 首先,我们思考一下,为什么TCP会有“三次握手四次...
  • TCP 状态转移

    2016-07-17 18:32:37
    TCP协议可靠传输协议,它的可靠性是有它的面向连接的性质所决定,在TCP连接与断开的时候会出现不同的状态,各种状态之间的存在相互转换,因此便有了状态转移机这个概念,下图就是TCP连接的11种状态之间的转换图 ...
  • TCP状态转移的原理并不高深,但是处理逻辑比较复杂,以下是TCP状态转移图。出自《TCP/IP协议详解:卷2》——W.Richard Stevens 这些状态是怎么实现的呢? 我们来看一下内核源代码。(server端部分)  ...
  • TCP状态转移图学习总结 (转)

    千次阅读 2012-09-28 22:08:00
    TCP状态转移图学习总结 (转) 这是网络编程的基础,tcp的状态转移图说到底就是一个状态机的不同状态之间的转换关系以及触发这些状态需要的条件,一共存在11个状态,我们来逐一分析: 1.CLOSED:起始点...
  • TCP 状态转移示意

    2018-03-16 15:12:54
  • TCP状态转移要点  TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能成功断开连接,如果缺少了其中某个步骤,将会使连接处于假死状态,连接本身占用的资源不会被释放。网络服务器程序要同时管理大量...
  • tcp状态转移

    2014-05-13 19:48:34
  • 这是网络编程的基础,tcp状态转移图说到底就是一个状态机的不同状态之间的转换关系以及触发这些状态需要的条件,一共存在11个状态,我们来逐一分析: 1.CLOSED:起始点,在超时或者连接关闭时候进入此状态。2....
  • 上两周无意中讨论起这个话题,发现andy同学对此甚为熟悉,...这是网络编程的基础,tcp状态转移图说到底就是一个状态机的不同状态之间的转换关系以及触发这些状态需要的条件,一共存在11个状态,我们来逐一分析:
  • [转]TCP状态转移图学习总结

    千次阅读 2012-12-27 14:44:43
    这是网络编程的基础,tcp状态转移图说到底就是一个状态机的不同状态之间的转换关系以及触发这些状态需要的条件,一共存在11个状态,我们来逐一分析: 1.CLOSED:起始点,在超时或者连接关闭时候进入此状态...
  • (转)TCP状态转移图学习总结

    千次阅读 2011-03-03 19:26:00
    这是网络编程的基础,tcp状态转移图说到底就是一个状态机的不同状态之间的转换关系以及触发这些状态需要的条件,一共存在11个状态,我们来逐一分析: <br />1.CLOSED:起始点,在超时或者连接关闭时候...
  • 目录 文章目录目录前文列表 前文列表 《常用 tcpdump 抓包方式》
  • TCP连接的状态转移

    2017-05-22 14:56:08
    TCP状态转移

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 41,037
精华内容 16,414
关键字:

tcp状态转移