标签:防止 需要 分配 时间戳 四次握手 lis 客户服务 协议 出现
TCP运输连接的三个阶段:
- 连接建立。
- 数据传送。
- 连接释放。
TCP连接建立过程中要解决的问题:
(1) 每一方能够确知对方的存在。
(2) 允许双方协商参数。如:最大窗口值,是否使用窗口扩大选项,是否使用时间戳选项,服务质量,……
(3) 能够对运输实体资源进行分配。如:缓存大小,连接表中的项目,……
TCP采用客户服务器方式建立连接:
客户(client):主动发起连接建立的应用进程。
服务器(server):被动等待连接建立的应用进程。
建立TCP连接
三次握手(three-way handshake)或三次联络,步骤:
- 最初两端的TCP都处在CLOSED(关闭)状态。
- B的TCP服务器进程创建传输控制块TCB,服务器进程进入LISTEN(收听)状态,等待客户的连接请求。
传输控制块:Transmission Control Block,TCB,存储连接中的信息。如:TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前发送和接收序号,……
- A的TCP客户进程创建传输控制块TCB,向B发出连接请求报文段。这时,首部中同步位SYN=1,初始序号seq=x。SYN报文段不携带数据,但要消耗一个序号。TCP客户进程进入SYN-SENT(同步已发送)状态。
- B收到连接请求报文段,如同意建立连接,则向A发送确认。确认报文段中,SYN和ACK都为1,确认号ack=x+1,并选择自己的初始序号seq=y。此报文段同样不携带数据,但要消耗一个序号。TCP服务器进程进入SYN-RCVD(同步接收)状态。
- TCP客户进程收到B的确认后,向B发出确认。确认报文段的ACK=1,确认号ack=y+1,自己的seq=x+1。ACK报文段可携带数据,不携带数据则不消耗序号。TCP连接已建立,A进入ESTABLISHED(已连接)状态。
- B收到A的确认,也进入ESTABLISHED状态。
A收到B的确认,为什么还要再次向B发送确认?
答:A向B发出连接请求报文段,如果此报文段在网络中长时间滞留,A误以为报文段丢失,会再次向B发送连接请求报文段(假设第二次请求连接建立成功)。当数据传输完成并释放连接后,B又收到A第一次发送的连接请求,B误以为A发起了一次新的连接请求。所以,A有必要让B知道是否发起了新的连接请求。
释放TCP连接
四次握手,步骤:
- 开始时,A和B都处在ESTABLISHED状态。
- A的应用进程向TCP发出连接释放报文段,停止发送数据,关闭TCP连接。A把报文段首部中FIN置为1,序号seq=u,u是已传送的数据的最后一个字节序号加1。A进入FIN-WAIT-1(终止等待1)状态,等待B的确认。FIN报文段即使不携带数据,也要消耗一个序号。
- B收到连接释放报文段向A发出确认,确认号ack=u+1,B自己的序号是v,v是已传送过的数据的最后一个字节加1。B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程通知高层应用进程,从A到B的连接被释放。TCP进入半关闭(half-close)状态。
- A收到B的确认,进入FIN-WAIT-2(终止等待2)状态,等待B发出连接释放报文段。
- B应用进程通知TCP释放连接,报文段首部FIN=1,序号为w(半关闭状态时B可能又发送了一些数据),B重复上次发送的确认号ack=u+1。B进入LAST-ACK(最后确认)状态,等待A的确认。
- A收到B的连接释放报文段,向B发出确认。确认报文段中ACK=1,确认号ack=w+1,A自己的序号seq=u+1(发送的FIN报文段使用一个序号)。A进入TIME-WAIT(时间等待)状态。
- 经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后,A进入CLOSED状态。
最长报文段寿命:Maximum Segment Lifetime,MSL,TCP允许根据不同情况调整此值,RFC 793建议时间2分钟。
- B收到A的确认,进入CLOSED状态,撤销传输控制块TCB,TCP连接释放成功。
**A为什么在TIME-WAIT状态等待2MSL时间?
答:
- 保证A发送的最后一个ACK报文段能够到达B。若此报文段丢失,处在LAST-ACK状态的B收不到FIN+ACK报文段的确认,B将超时重传FIN+ACK报文段,A可在2MSL时间内收到重传的FIN+ACK报文段。A重传确认,重新启动2MSL计时器。保证A和B顺利进入CLOSED状态。
- 防止“已失效连接请求报文段”。A等待2MSL,可使本连接持续时间内所产生的所有报文段全部从网络中消失。**
什么是时间保活计时器?为什么设置时间保活计时器?
答:
时间保活计时器(keepalive timer):服务器每收到一次数据,就重新设置保活计时器,时间2小时。超时后还未收到客户数据,服务器发送探测报文段,以后每隔75分钟发送一次。连续发送10个探测报文段客户仍无响应,服务器关闭TCP连接。
设置保活计时器的原因:处在TCP连接状态时,A出现故障,防止B一直等待下去。
TCP有限状态机
方框:TCP状态。
箭头:状态变迁。
箭头旁边的字:1.引起状态变迁的原因。2.发生状态变迁后出现的动作。
粗实线箭头:客户进程的正常变迁。
粗虚线箭头:服务器进程的正常变迁。
细线箭头:异常变迁。
作者:
链接:https://www.imooc.com/article/17411
来源:慕课网
TCP运输连接的三个阶段:
- 连接建立。
- 数据传送。
- 连接释放。
TCP连接建立过程中要解决的问题:
(1) 每一方能够确知对方的存在。
(2) 允许双方协商参数。如:最大窗口值,是否使用窗口扩大选项,是否使用时间戳选项,服务质量,……
(3) 能够对运输实体资源进行分配。如:缓存大小,连接表中的项目,……
TCP采用客户服务器方式建立连接:
客户(client):主动发起连接建立的应用进程。
服务器(server):被动等待连接建立的应用进程。
建立TCP连接
三次握手(three-way handshake)或三次联络,步骤:
- 最初两端的TCP都处在CLOSED(关闭)状态。
- B的TCP服务器进程创建传输控制块TCB,服务器进程进入LISTEN(收听)状态,等待客户的连接请求。
传输控制块:Transmission Control Block,TCB,存储连接中的信息。如:TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前发送和接收序号,……
- A的TCP客户进程创建传输控制块TCB,向B发出连接请求报文段。这时,首部中同步位SYN=1,初始序号seq=x。SYN报文段不携带数据,但要消耗一个序号。TCP客户进程进入SYN-SENT(同步已发送)状态。
- B收到连接请求报文段,如同意建立连接,则向A发送确认。确认报文段中,SYN和ACK都为1,确认号ack=x+1,并选择自己的初始序号seq=y。此报文段同样不携带数据,但要消耗一个序号。TCP服务器进程进入SYN-RCVD(同步接收)状态。
- TCP客户进程收到B的确认后,向B发出确认。确认报文段的ACK=1,确认号ack=y+1,自己的seq=x+1。ACK报文段可携带数据,不携带数据则不消耗序号。TCP连接已建立,A进入ESTABLISHED(已连接)状态。
- B收到A的确认,也进入ESTABLISHED状态。
A收到B的确认,为什么还要再次向B发送确认?
答:A向B发出连接请求报文段,如果此报文段在网络中长时间滞留,A误以为报文段丢失,会再次向B发送连接请求报文段(假设第二次请求连接建立成功)。当数据传输完成并释放连接后,B又收到A第一次发送的连接请求,B误以为A发起了一次新的连接请求。所以,A有必要让B知道是否发起了新的连接请求。
释放TCP连接
四次握手,步骤:
- 开始时,A和B都处在ESTABLISHED状态。
- A的应用进程向TCP发出连接释放报文段,停止发送数据,关闭TCP连接。A把报文段首部中FIN置为1,序号seq=u,u是已传送的数据的最后一个字节序号加1。A进入FIN-WAIT-1(终止等待1)状态,等待B的确认。FIN报文段即使不携带数据,也要消耗一个序号。
- B收到连接释放报文段向A发出确认,确认号ack=u+1,B自己的序号是v,v是已传送过的数据的最后一个字节加1。B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程通知高层应用进程,从A到B的连接被释放。TCP进入半关闭(half-close)状态。
- A收到B的确认,进入FIN-WAIT-2(终止等待2)状态,等待B发出连接释放报文段。
- B应用进程通知TCP释放连接,报文段首部FIN=1,序号为w(半关闭状态时B可能又发送了一些数据),B重复上次发送的确认号ack=u+1。B进入LAST-ACK(最后确认)状态,等待A的确认。
- A收到B的连接释放报文段,向B发出确认。确认报文段中ACK=1,确认号ack=w+1,A自己的序号seq=u+1(发送的FIN报文段使用一个序号)。A进入TIME-WAIT(时间等待)状态。
- 经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后,A进入CLOSED状态。
最长报文段寿命:Maximum Segment Lifetime,MSL,TCP允许根据不同情况调整此值,RFC 793建议时间2分钟。
- B收到A的确认,进入CLOSED状态,撤销传输控制块TCB,TCP连接释放成功。
**A为什么在TIME-WAIT状态等待2MSL时间?
答:
- 保证A发送的最后一个ACK报文段能够到达B。若此报文段丢失,处在LAST-ACK状态的B收不到FIN+ACK报文段的确认,B将超时重传FIN+ACK报文段,A可在2MSL时间内收到重传的FIN+ACK报文段。A重传确认,重新启动2MSL计时器。保证A和B顺利进入CLOSED状态。
- 防止“已失效连接请求报文段”。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运输连接的三个阶段:
- 连接建立。
- 数据传送。
- 连接释放。
TCP连接建立过程中要解决的问题:
(1) 每一方能够确知对方的存在。
(2) 允许双方协商参数。如:最大窗口值,是否使用窗口扩大选项,是否使用时间戳选项,服务质量,……
(3) 能够对运输实体资源进行分配。如:缓存大小,连接表中的项目,……
TCP采用客户服务器方式建立连接:
客户(client):主动发起连接建立的应用进程。
服务器(server):被动等待连接建立的应用进程。
建立TCP连接
三次握手(three-way handshake)或三次联络,步骤:
- 最初两端的TCP都处在CLOSED(关闭)状态。
- B的TCP服务器进程创建传输控制块TCB,服务器进程进入LISTEN(收听)状态,等待客户的连接请求。
传输控制块:Transmission Control Block,TCB,存储连接中的信息。如:TCP连接表,到发送和接收缓存的指针,到重传队列的指针,当前发送和接收序号,……
- A的TCP客户进程创建传输控制块TCB,向B发出连接请求报文段。这时,首部中同步位SYN=1,初始序号seq=x。SYN报文段不携带数据,但要消耗一个序号。TCP客户进程进入SYN-SENT(同步已发送)状态。
- B收到连接请求报文段,如同意建立连接,则向A发送确认。确认报文段中,SYN和ACK都为1,确认号ack=x+1,并选择自己的初始序号seq=y。此报文段同样不携带数据,但要消耗一个序号。TCP服务器进程进入SYN-RCVD(同步接收)状态。
- TCP客户进程收到B的确认后,向B发出确认。确认报文段的ACK=1,确认号ack=y+1,自己的seq=x+1。ACK报文段可携带数据,不携带数据则不消耗序号。TCP连接已建立,A进入ESTABLISHED(已连接)状态。
- B收到A的确认,也进入ESTABLISHED状态。
A收到B的确认,为什么还要再次向B发送确认?
答:A向B发出连接请求报文段,如果此报文段在网络中长时间滞留,A误以为报文段丢失,会再次向B发送连接请求报文段(假设第二次请求连接建立成功)。当数据传输完成并释放连接后,B又收到A第一次发送的连接请求,B误以为A发起了一次新的连接请求。所以,A有必要让B知道是否发起了新的连接请求。
释放TCP连接
四次握手,步骤:
- 开始时,A和B都处在ESTABLISHED状态。
- A的应用进程向TCP发出连接释放报文段,停止发送数据,关闭TCP连接。A把报文段首部中FIN置为1,序号seq=u,u是已传送的数据的最后一个字节序号加1。A进入FIN-WAIT-1(终止等待1)状态,等待B的确认。FIN报文段即使不携带数据,也要消耗一个序号。
- B收到连接释放报文段向A发出确认,确认号ack=u+1,B自己的序号是v,v是已传送过的数据的最后一个字节加1。B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程通知高层应用进程,从A到B的连接被释放。TCP进入半关闭(half-close)状态。
- A收到B的确认,进入FIN-WAIT-2(终止等待2)状态,等待B发出连接释放报文段。
- B应用进程通知TCP释放连接,报文段首部FIN=1,序号为w(半关闭状态时B可能又发送了一些数据),B重复上次发送的确认号ack=u+1。B进入LAST-ACK(最后确认)状态,等待A的确认。
- A收到B的连接释放报文段,向B发出确认。确认报文段中ACK=1,确认号ack=w+1,A自己的序号seq=u+1(发送的FIN报文段使用一个序号)。A进入TIME-WAIT(时间等待)状态。
- 经过时间等待计时器(TIME-WAIT
timer)设置的时间2MSL后,A进入CLOSED状态。
最长报文段寿命:Maximum Segment Lifetime,MSL,TCP允许根据不同情况调整此值,RFC 793建议时间2分钟。
- B收到A的确认,进入CLOSED状态,撤销传输控制块TCB,TCP连接释放成功。
**A为什么在TIME-WAIT状态等待2MSL时间?
答:
- 保证A发送的最后一个ACK报文段能够到达B。若此报文段丢失,处在LAST-ACK状态的B收不到FIN+ACK报文段的确认,B将超时重传FIN+ACK报文段,A可在2MSL时间内收到重传的FIN+ACK报文段。A重传确认,重新启动2MSL计时器。保证A和B顺利进入CLOSED状态。
- 防止“已失效连接请求报文段”。A等待2MSL,可使本连接持续时间内所产生的所有报文段全部从网络中消失。**
什么是时间保活计时器?为什么设置时间保活计时器?
答:
时间保活计时器(keepalive timer):服务器每收到一次数据,就重新设置保活计时器,时间2小时。超时后还未收到客户数据,服务器发送探测报文段,以后每隔75分钟发送一次。连续发送10个探测报文段客户仍无响应,服务器关闭TCP连接。
设置保活计时器的原因:处在TCP连接状态时,A出现故障,防止B一直等待下去。
TCP有限状态机
方框:TCP状态。
箭头:状态变迁。
箭头旁边的字:1.引起状态变迁的原因。2.发生状态变迁后出现的动作。
粗实线箭头:客户进程的正常变迁。
粗虚线箭头:服务器进程的正常变迁。
细线箭头:异常变迁。
TCP的连接和释放
标签:防止 需要 分配 时间戳 四次握手 lis 客户服务 协议 出现
原文地址:https://www.cnblogs.com/huifeidezhuzai/p/9227122.html