乐趣区

关于计算机网络:计算机网络TCP连接管理

1. TCP 连贯的建设

TCP 建设连贯的过程须要在客户端和服务端之间替换 3 个 TCP 报文段,故而也称为“三次握手”。

假如 A 运行 TCP 客户端程序,B 运行 TCP 服务端程序,则三次握手过程如下所示:

服务端 B 执行的代码大抵如下:

struct sockaddr addr;
int listenSock, backlog, clientSock;

// 设置各变量 ...

listenSock = socket(AF_INET, SOCK_STREAM, 0);
bind(listenSock, &addr, sizoef(addr));
listen(listenSock, backlog);
clientSock = accept(listenSock, NULL, NULL);

客户端 A 执行的代码大抵如下:

struct sockaddr serverAddr;
int sock;

// 设置各变量 ...

sock = socket(AF_INET, SOCK_STREAM, 0);
connect(sock, &serverAddr, sizeof(serverAddr));
  • 两者通过调用 socket() 来创立 TCP 套接字,此时两者处于 CLOSED 状态;
  • 服务端 B 先运行,在调用 listen() 之后,进入 LISTEN 状态,监听客户端连贯申请;
  • A 调用 connect() 向 B 发动建设连贯的申请:A 向 B 发送一个 SYN 报文段,其中的同步位 SYN=1,同时抉择一个初始序号 seq=x;SYN 报文段不能携带数据,但要耗费一个序号,在发送完 SYN 报文段之后,进入 SYN_SENT 状态;
  • B 收到 A 的连贯申请报文后进入 SYN_RCVD 状态,如果批准建设连贯,则调用 accept(),而后向 A 发送确认:确认报文段的 SYN=1、ACK=1,确认号为 ack=x+1,同时为本人抉择一个初始序号 seq=y,此报文段也不能携带数据,但要耗费一个序号;
  • A 收到 B 的确认后,还要向 B 返回确认,而后进入 ESTABLISHED 状态:确认报文的 ACK=1,确认序号为 ack=y+1,而本人的序号为 seq=x+1,此报文段能够携带数据,如果不携带数据则不耗费序号(下一个报文段的序号仍为 seq=x+1);
  • B 收到 A 的确认后也进入 ESTABLISHED 状态。

为什么 A 最初还要发送一次确认? 次要是为了避免已生效的连贯申请报文段忽然又传送到了 B:如果 A 收回的第一个连贯申请报文段因为网络提早没有及时达到 B;此时 A 收回第二个连贯申请报文段,且胜利建设了连贯,数据传输结束后,开释了连贯;一段时间后,第一个连贯申请报文段终于达到了 B(B 认为是一个新的连贯申请),如果 B 不须要 A 的确认就建设了连贯,而 A 又不理睬 B 的确认,则 B 就白白浪费了资源。

2. TCP 连贯的开释

假如 A 被动敞开连贯,则连贯的开释过程如下:

  • A 通过调用 close() 来敞开套接字,向 B 发送连贯开释报文段:报文段的 FIN=1,序号 seq=u;而后进入 FIN-WAIT-1 状态,期待 B 的确认;FIN 报文段不能携带数据,但要耗费一个序号;
  • B 收到连贯开释报文段后立刻收回确认:确认报文段的 ACK=1,确认号为 ack=u+1,序号为 seq=v;而后进入 CLOSE-WAIT 状态(期待己方敞开连贯);此时的 TCP 连贯处于半敞开状态,即 A 曾经没有数据要发送了,但如果 B 发送数据,A 仍要接管,也就是说 B 到 A 这个方向的连贯仍未敞开;
  • A 收到 B 的确认后进入 FIN-WAIT-2 状态,期待 B 发送连贯开释报文段;
  • B 发送完数据之后也调用 close() 来敞开连贯,向 A 发送连贯开释报文段:报文段的 FIN=1,ACK=1,序号为 seq=w,确认号仍为 ack=u+1;而后进入 LAST-ACK 状态,期待 A 的确认(最初一个确认);
  • A 收到 B 的连贯开释报文段后,向 B 收回确认:报文段的 ACK=1,序号为 seq=u+1,确认号为 ack=w+1;而后进入 TIME-WAIT 状态,此时连贯仍未开释;
  • B 收到 A 的确认后开释连贯,进入 CLOSED 状态;
  • A 在 TIME-WAIT 状态中期待 2MSL(Maximum Segment Lifetime)的工夫之后才进入到 CLOSED 状态,即 B 先于 A 完结 TCP 连贯。

为什么 A 须要在 TIME-WAIT 状态中期待 2MSL 的工夫? 起因有如下两点:
(1)为了保障 A 发送的最初一个 ACK 报文段可能达到 B。如果此 ACK 报文段失落,B 会因为没收到确认而超时重传 FIN+ACK 报文段,而 A 就可能在这 2MSL 工夫内收到重传的 FIN+ACK 报文段,而后 A 重传一次确认,并重新启动 2MSL 计时器。
(2)A 在发送完最初一个 ACK 报文段后,再通过 2MSL 工夫,就能够使本连贯期间所产生的所有报文段都从网络中隐没,这样就可保障新连贯中不会呈现旧连贯的申请报文段。

退出移动版