TCP的连接和释放

TCP运输连接的三个阶段：

1. 连接建立。
2. 数据传送。
3. 连接释放。
   TCP连接建立过程中要解决的问题：
   （1） 每一方能够确知对方的存在。
   （2） 允许双方协商参数。如：最大窗口值，是否使用窗口扩大选项，是否使用时间戳选项，服务质量，……
   （3） 能够对运输实体资源进行分配。如：缓存大小，连接表中的项目，……
   TCP采用客户服务器方式建立连接：
   客户（client）：主动发起连接建立的应用进程。
   服务器（server）：被动等待连接建立的应用进程。

建立TCP连接

三次握手（three-way handshake）或三次联络，步骤：

1. 最初两端的TCP都处在CLOSED（关闭）状态。
2. B的TCP服务器进程创建传输控制块TCB，服务器进程进入LISTEN（收听）状态，等待客户的连接请求。
   传输控制块：Transmission Control Block，TCB，存储连接中的信息。如：TCP连接表，到发送和接收缓存的指针，到重传队列的指针，当前发送和接收序号，……
3. A的TCP客户进程创建传输控制块TCB，向B发出连接请求报文段。这时，首部中同步位SYN=1，初始序号seq=x。SYN报文段不携带数据，但要消耗一个序号。TCP客户进程进入SYN-SENT（同步已发送）状态。
4. B收到连接请求报文段，如同意建立连接，则向A发送确认。确认报文段中，SYN和ACK都为1，确认号ack=x+1，并选择自己的初始序号seq=y。此报文段同样不携带数据，但要消耗一个序号。TCP服务器进程进入SYN-RCVD（同步接收）状态。
5. TCP客户进程收到B的确认后，向B发出确认。确认报文段的ACK=1，确认号ack=y+1，自己的seq=x+1。ACK报文段可携带数据，不携带数据则不消耗序号。TCP连接已建立，A进入ESTABLISHED（已连接）状态。
6. B收到A的确认，也进入ESTABLISHED状态。

A收到B的确认，为什么还要再次向B发送确认？
答：A向B发出连接请求报文段，如果此报文段在网络中长时间滞留，A误以为报文段丢失，会再次向B发送连接请求报文段（假设第二次请求连接建立成功）。当数据传输完成并释放连接后，B又收到A第一次发送的连接请求，B误以为A发起了一次新的连接请求。所以，A有必要让B知道是否发起了新的连接请求。

释放TCP连接

四次握手，步骤：

1. 开始时，A和B都处在ESTABLISHED状态。
2. A的应用进程向TCP发出连接释放报文段，停止发送数据，关闭TCP连接。A把报文段首部中FIN置为1，序号seq=u，u是已传送的数据的最后一个字节序号加1。A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。FIN报文段即使不携带数据，也要消耗一个序号。
3. B收到连接释放报文段向A发出确认，确认号ack=u+1，B自己的序号是v，v是已传送过的数据的最后一个字节加1。B进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程通知高层应用进程，从A到B的连接被释放。TCP进入半关闭（half-close）状态。
4. A收到B的确认，进入FIN-WAIT-2（终止等待2）状态，等待B发出连接释放报文段。
5. B应用进程通知TCP释放连接，报文段首部FIN=1，序号为w（半关闭状态时B可能又发送了一些数据），B重复上次发送的确认号ack=u+1。B进入LAST-ACK（最后确认）状态，等待A的确认。
6. A收到B的连接释放报文段，向B发出确认。确认报文段中ACK=1，确认号ack=w+1，A自己的序号seq=u+1（发送的FIN报文段使用一个序号）。A进入TIME-WAIT（时间等待）状态。
7. 经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A进入CLOSED状态。
   最长报文段寿命：Maximum Segment Lifetime，MSL，TCP允许根据不同情况调整此值，RFC 793建议时间2分钟。
8. B收到A的确认，进入CLOSED状态，撤销传输控制块TCB，TCP连接释放成功。

**A为什么在TIME-WAIT状态等待2MSL时间？
答：

1. 保证A发送的最后一个ACK报文段能够到达B。若此报文段丢失，处在LAST-ACK状态的B收不到FIN+ACK报文段的确认，B将超时重传FIN+ACK报文段，A可在2MSL时间内收到重传的FIN+ACK报文段。A重传确认，重新启动2MSL计时器。保证A和B顺利进入CLOSED状态。
2. 防止“已失效连接请求报文段”。A等待2MSL，可使本连接持续时间内所产生的所有报文段全部从网络中消失。**

什么是时间保活计时器？为什么设置时间保活计时器？
答：
时间保活计时器（keepalive timer）：服务器每收到一次数据，就重新设置保活计时器，时间2小时。超时后还未收到客户数据，服务器发送探测报文段，以后每隔75分钟发送一次。连续发送10个探测报文段客户仍无响应，服务器关闭TCP连接。
设置保活计时器的原因：处在TCP连接状态时，A出现故障，防止B一直等待下去。

TCP有限状态机

方框：TCP状态。
箭头：状态变迁。
箭头旁边的字：1.引起状态变迁的原因。2.发生状态变迁后出现的动作。
粗实线箭头：客户进程的正常变迁。
粗虚线箭头：服务器进程的正常变迁。
细线箭头：异常变迁。

作者：
链接：https://www.imooc.com/article/17411
来源：慕课网

TCP运输连接的三个阶段：

1. 连接建立。
2. 数据传送。
3. 连接释放。
   TCP连接建立过程中要解决的问题：
   （1） 每一方能够确知对方的存在。
   （2） 允许双方协商参数。如：最大窗口值，是否使用窗口扩大选项，是否使用时间戳选项，服务质量，……
   （3） 能够对运输实体资源进行分配。如：缓存大小，连接表中的项目，……
   TCP采用客户服务器方式建立连接：
   客户（client）：主动发起连接建立的应用进程。
   服务器（server）：被动等待连接建立的应用进程。

建立TCP连接

三次握手（three-way handshake）或三次联络，步骤：

1. 最初两端的TCP都处在CLOSED（关闭）状态。
2. B的TCP服务器进程创建传输控制块TCB，服务器进程进入LISTEN（收听）状态，等待客户的连接请求。
   传输控制块：Transmission Control Block，TCB，存储连接中的信息。如：TCP连接表，到发送和接收缓存的指针，到重传队列的指针，当前发送和接收序号，……
3. A的TCP客户进程创建传输控制块TCB，向B发出连接请求报文段。这时，首部中同步位SYN=1，初始序号seq=x。SYN报文段不携带数据，但要消耗一个序号。TCP客户进程进入SYN-SENT（同步已发送）状态。
4. B收到连接请求报文段，如同意建立连接，则向A发送确认。确认报文段中，SYN和ACK都为1，确认号ack=x+1，并选择自己的初始序号seq=y。此报文段同样不携带数据，但要消耗一个序号。TCP服务器进程进入SYN-RCVD（同步接收）状态。
5. TCP客户进程收到B的确认后，向B发出确认。确认报文段的ACK=1，确认号ack=y+1，自己的seq=x+1。ACK报文段可携带数据，不携带数据则不消耗序号。TCP连接已建立，A进入ESTABLISHED（已连接）状态。
6. B收到A的确认，也进入ESTABLISHED状态。

A收到B的确认，为什么还要再次向B发送确认？
答：A向B发出连接请求报文段，如果此报文段在网络中长时间滞留，A误以为报文段丢失，会再次向B发送连接请求报文段（假设第二次请求连接建立成功）。当数据传输完成并释放连接后，B又收到A第一次发送的连接请求，B误以为A发起了一次新的连接请求。所以，A有必要让B知道是否发起了新的连接请求。

释放TCP连接

四次握手，步骤：

1. 开始时，A和B都处在ESTABLISHED状态。
2. A的应用进程向TCP发出连接释放报文段，停止发送数据，关闭TCP连接。A把报文段首部中FIN置为1，序号seq=u，u是已传送的数据的最后一个字节序号加1。A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。FIN报文段即使不携带数据，也要消耗一个序号。
3. B收到连接释放报文段向A发出确认，确认号ack=u+1，B自己的序号是v，v是已传送过的数据的最后一个字节加1。B进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程通知高层应用进程，从A到B的连接被释放。TCP进入半关闭（half-close）状态。
4. A收到B的确认，进入FIN-WAIT-2（终止等待2）状态，等待B发出连接释放报文段。
5. B应用进程通知TCP释放连接，报文段首部FIN=1，序号为w（半关闭状态时B可能又发送了一些数据），B重复上次发送的确认号ack=u+1。B进入LAST-ACK（最后确认）状态，等待A的确认。
6. A收到B的连接释放报文段，向B发出确认。确认报文段中ACK=1，确认号ack=w+1，A自己的序号seq=u+1（发送的FIN报文段使用一个序号）。A进入TIME-WAIT（时间等待）状态。
7. 经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A进入CLOSED状态。
   最长报文段寿命：Maximum Segment Lifetime，MSL，TCP允许根据不同情况调整此值，RFC 793建议时间2分钟。
8. B收到A的确认，进入CLOSED状态，撤销传输控制块TCB，TCP连接释放成功。

**A为什么在TIME-WAIT状态等待2MSL时间？
答：

1. 保证A发送的最后一个ACK报文段能够到达B。若此报文段丢失，处在LAST-ACK状态的B收不到FIN+ACK报文段的确认，B将超时重传FIN+ACK报文段，A可在2MSL时间内收到重传的FIN+ACK报文段。A重传确认，重新启动2MSL计时器。保证A和B顺利进入CLOSED状态。
2. 防止“已失效连接请求报文段”。A等待2MSL，可使本连接持续时间内所产生的所有报文段全部从网络中消失。**

什么是时间保活计时器？为什么设置时间保活计时器？
答：
时间保活计时器（keepalive timer）：服务器每收到一次数据，就重新设置保活计时器，时间2小时。超时后还未收到客户数据，服务器发送探测报文段，以后每隔75分钟发送一次。连续发送10个探测报文段客户仍无响应，服务器关闭TCP连接。
设置保活计时器的原因：处在TCP连接状态时，A出现故障，防止B一直等待下去。

TCP有限状态机

方框：TCP状态。
箭头：状态变迁。
箭头旁边的字：1.引起状态变迁的原因。2.发生状态变迁后出现的动作。
粗实线箭头：客户进程的正常变迁。
粗虚线箭头：服务器进程的正常变迁。
细线箭头：异常变迁。

作者：
链接：https://www.imooc.com/article/17411
来源：慕课网

实行标准

TCP/IP(Transmission Control Protocol/Internet Protocol) 即传输控制协议/网间协议，是一个工业标准的协议集，它是为广域网（WAN）设计的。它是由ARPANET网的研究机构发展起来的。

TCP/IP的标准在一系列称为RF ^[1】C的文档中公布。文档由技术专家、特别工作组、或RFC编辑修订。公布一个文档时，该文档被赋予一个RFC编号，如RFC959（FTP的说明文档）、RFC793（TCP的说明文档）、RFC791（IP的说明文档）等。最初的RFC一直保留而从来不会被更新， ^[1]  如果修改了该文档，则该文档又以一个新号码公布。因此，重要的是要确认你拥有了关于某个专题的最新RFC文档。通常在RFC的开头部分，有相关RFC的更新(update)、排错（errata）、作废（obsolete）信息，提示读者信息的时效性。

首部格式

TCP的首部格式图右图所示：

---Source Port是源端口，16位。

TCP首部

---Destination Port是目的端口，16位。

---Sequence Number是发送数据包中的第一个字节的序列号，32位。

---Acknowledgment Number是确认序列号，32位。

---Data Offset是数据偏移，4位，该字段的值是TCP首部（包括选项）长度除以4。 ^[1] 

---标志位： 6位，URG表示Urgent Pointer字段有意义：

ACK表示Acknowledgment Number字段有意义

PSH表示Push功能，RST表示复位TCP连接

SYN表示SYN报文（在建立TCP连接的时候使用）

FIN表示没有数据需要发送了（在关闭TCP连接的时候使用）

Window表示接收缓冲区的空闲空间，16位，用来告诉TCP连接对端自己能够接收的最大数据长度。

---Checksum是校验和，16位。

---Urgent Pointers是紧急指针，16位，只有URG标志位被设置时该字段才有意义，表示紧急数据相对序列号（Sequence Number字段的值）的偏移。

TCP运输连接的三个阶段：

1. 连接建立。
2. 数据传送。
3. 连接释放。
   TCP连接建立过程中要解决的问题：
   （1） 每一方能够确知对方的存在。
   （2） 允许双方协商参数。如：最大窗口值，是否使用窗口扩大选项，是否使用时间戳选项，服务质量，……
   （3） 能够对运输实体资源进行分配。如：缓存大小，连接表中的项目，……
   TCP采用客户服务器方式建立连接：
   客户（client）：主动发起连接建立的应用进程。
   服务器（server）：被动等待连接建立的应用进程。

建立TCP连接

三次握手（three-way handshake）或三次联络，步骤：

1. 最初两端的TCP都处在CLOSED（关闭）状态。
2. B的TCP服务器进程创建传输控制块TCB，服务器进程进入LISTEN（收听）状态，等待客户的连接请求。
   传输控制块：Transmission Control Block，TCB，存储连接中的信息。如：TCP连接表，到发送和接收缓存的指针，到重传队列的指针，当前发送和接收序号，……
3. A的TCP客户进程创建传输控制块TCB，向B发出连接请求报文段。这时，首部中同步位SYN=1，初始序号seq=x。SYN报文段不携带数据，但要消耗一个序号。TCP客户进程进入SYN-SENT（同步已发送）状态。
4. B收到连接请求报文段，如同意建立连接，则向A发送确认。确认报文段中，SYN和ACK都为1，确认号ack=x+1，并选择自己的初始序号seq=y。此报文段同样不携带数据，但要消耗一个序号。TCP服务器进程进入SYN-RCVD（同步接收）状态。
5. TCP客户进程收到B的确认后，向B发出确认。确认报文段的ACK=1，确认号ack=y+1，自己的seq=x+1。ACK报文段可携带数据，不携带数据则不消耗序号。TCP连接已建立，A进入ESTABLISHED（已连接）状态。
6. B收到A的确认，也进入ESTABLISHED状态。

A收到B的确认，为什么还要再次向B发送确认？
答：A向B发出连接请求报文段，如果此报文段在网络中长时间滞留，A误以为报文段丢失，会再次向B发送连接请求报文段（假设第二次请求连接建立成功）。当数据传输完成并释放连接后，B又收到A第一次发送的连接请求，B误以为A发起了一次新的连接请求。所以，A有必要让B知道是否发起了新的连接请求。

 

释放TCP连接

四次握手，步骤：

1. 开始时，A和B都处在ESTABLISHED状态。
2. A的应用进程向TCP发出连接释放报文段，停止发送数据，关闭TCP连接。A把报文段首部中FIN置为1，序号seq=u，u是已传送的数据的最后一个字节序号加1。A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。FIN报文段即使不携带数据，也要消耗一个序号。
3. B收到连接释放报文段向A发出确认，确认号ack=u+1，B自己的序号是v，v是已传送过的数据的最后一个字节加1。B进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程通知高层应用进程，从A到B的连接被释放。TCP进入半关闭（half-close）状态。
4. A收到B的确认，进入FIN-WAIT-2（终止等待2）状态，等待B发出连接释放报文段。
5. B应用进程通知TCP释放连接，报文段首部FIN=1，序号为w（半关闭状态时B可能又发送了一些数据），B重复上次发送的确认号ack=u+1。B进入LAST-ACK（最后确认）状态，等待A的确认。
6. A收到B的连接释放报文段，向B发出确认。确认报文段中ACK=1，确认号ack=w+1，A自己的序号seq=u+1（发送的FIN报文段使用一个序号）。A进入TIME-WAIT（时间等待）状态。
7. 经过时间等待计时器（TIME-WAIT timer）设置的时间2MSL后，A进入CLOSED状态。
   最长报文段寿命：Maximum Segment Lifetime，MSL，TCP允许根据不同情况调整此值，RFC 793建议时间2分钟。
8. B收到A的确认，进入CLOSED状态，撤销传输控制块TCB，TCP连接释放成功。

 

**A为什么在TIME-WAIT状态等待2MSL时间？
答：

1. 保证A发送的最后一个ACK报文段能够到达B。若此报文段丢失，处在LAST-ACK状态的B收不到FIN+ACK报文段的确认，B将超时重传FIN+ACK报文段，A可在2MSL时间内收到重传的FIN+ACK报文段。A重传确认，重新启动2MSL计时器。保证A和B顺利进入CLOSED状态。
2. 防止“已失效连接请求报文段”。A等待2MSL，可使本连接持续时间内所产生的所有报文段全部从网络中消失。**

什么是时间保活计时器？为什么设置时间保活计时器？
答：
时间保活计时器（keepalive timer）：服务器每收到一次数据，就重新设置保活计时器，时间2小时。超时后还未收到客户数据，服务器发送探测报文段，以后每隔75分钟发送一次。连续发送10个探测报文段客户仍无响应，服务器关闭TCP连接。
设置保活计时器的原因：处在TCP连接状态时，A出现故障，防止B一直等待下去。

TCP有限状态机

方框：TCP状态。
箭头：状态变迁。
箭头旁边的字：1.引起状态变迁的原因。2.发生状态变迁后出现的动作。
粗实线箭头：客户进程的正常变迁。
粗虚线箭头：服务器进程的正常变迁。
细线箭头：异常变迁。