TCP三次握手和Time-Wait状态

时间：2022-06-21 14:14:38
  • 第一次握手：建立连接时。client发送syn包和一个随机序列号seq=x到server，并进入SYN_SEND状态，等待server进行确认。

    （syn，同 步序列编号）。

  • 第二次握手，server收到syn包，必须确认客户的SYN。然后server发送一个ACK=1, SYN=1, seq=y的随机数和ack=x+1的确认数的包发送回去。
  • 第三次握手是client收到server端的SYN+ACK包，然后向server端发送确认包 ack=y+1, seq=x+1, ACK=1,client和server端进入ESTABLISHED状态，完毕三次握手。详细图演示样例如以下(ACK表示首部中的ACK位置1。ack表示首部中确认序号字段的值)：

TCP三次握手和Time-Wait状态

TCP三次握手和Time-Wait状态

这里多说一点，既然提到了连接时的三次握手，就顺便把断开连接时的四次挥手也复习一下。

  • 首先client主动发送Fin=1，seq=u。它等于前面已传 送过去的最后一个字节的序号加1.这时A进入FIN-WAIT-1状态。等待B的确认。
  • B收到连接后马上发出确认。确认号是ack=u+1，而这个报文段 自己的序号是v。等于B前面已传送过的数据的最后一个字节的序号加1.然后B即进入CLOSE-WAIT状态。因而A到B的这个链接如今已经断开了，这时 的TCP连接处于半关闭状态。即A已经没有数据须要发送了。

    但B若发送数据，A还是要接受的。A收到来自B的确认之后就进入了FIN-WAIT-2状态等 待B发出连接释放报文段。

  • 若B已经没有要向A发送数据。其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使用FIN=1.如今假定B的序 号为w，B还必须反复上次已发送过的确认号ack=u+1.这时B就进入了LAST-ACK状态。等待A确认。
  • A在收到B的连接释放之后必须对此发出确 认。在确认号中把ACK置1。确认号ack=w+1,而自己的序号是seq=u+1。接着A进入TIME-WAIT状态。为了保证B能够收到确认释放报文段。

    例如以下图：

TCP三次握手和Time-Wait状态

是不是全部运行主动关闭的socket都会进入TIME_WAIT状态呢？

有没有什么情况使主动关闭的socket直接进入CLOSED状态呢？

主动关闭的一方在发送最后一个 ack 后

就会进入 TIME_WAIT 状态 停留2MSL（max segment lifetime）时间

这个是TCP/IP不可缺少的，也就是“解决”不了的。也就是TCP/IP设计者本来是这么设计的

主要有两个原因:

  1. 防止上一次连接中的包，迷路后又一次出现，影响新连接

    （经过2MSL，上一次连接中全部的反复包都会消失）
  2. 可靠的关闭TCP连接

    在主动关闭方发送的最后一个 ack(fin) ，有可能丢失。这时被动方会又一次发

    fin, 假设这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以

    主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。

$(function () {
$('pre.prettyprint code').each(function () {
var lines = $(this).text().split('\n').length;
var $numbering = $('

    ').addClass('pre-numbering').hide();
    $(this).addClass('has-numbering').parent().append($numbering);
    for (i = 1; i ').text(i));
    };
    $numbering.fadeIn(1700);
    });
    });

    相关文章