Nginx 基础入门篇 .4

本文详细介绍了TCP/IP协议中的连接建立(三次握手)和连接关闭(四次挥手)过程,包括每个步骤的描述及TCP的重要计时器作用,如重传计时器、持久计时器、保活计时器和时间等待计时器。此外,还提及了TCP的流控机制,确保数据传输的稳定性和效率。
摘要由CSDN通过智能技术生成

关于链接的问题

OSI封装回顾

在这里插入图片描述

TCP封装结构

在这里插入图片描述

TCP三次握手

在这里插入图片描述

step1:第一次握手
建立连接时,客户端发送SYN包到服务器,其中包含客户端的初始序号seq=x,并进入SYN_SENT状态,等待服务器确认。(其中,SYN=1,ACK=0,表示这是一个TCP连接请求数据报文;序号seq=x,表明传输数据时的第一个数据字节的序号是x)。

step2:第二次握手
服务器收到请求后,必须确认客户的数据包。同时自己也发送一个SYN包,即SYN+ACK包,此时服务器进入SYN_RECV状态。(其中确认报文段中,标识位SYN=1,ACK=1,表示这是一个TCP连接响应数据报文,并含服务端的初始序号seq(服务器)=y,以及服务器对客户端初始序号的确认号ack(服务器)=seq(客户端)+1=x+1)。

step3:第三次握手
客户端收到服务器的SYN+ACK包,向服务器发送一个序列号(seq=x+1),确认号为ack(客户端)=y+1,此包发送完毕,客户端和服务器进入ESTAB_LISHED(TCP连接成功)状态,完成三次握手。

未连接队列
在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包时,删除该条目,服务器进入ESTAB_LISHED状态。

TCP四次挥手/四次断开

在这里插入图片描述

step1:第一次挥手
首先,客户端发送一个FIN,用来关闭客户端到服务器的数据传送,然后等待服务器的确认。其中终止标志位FIN=1,序列号seq=u。

step2:第二次挥手
服务器收到这个FIN,它发送一个ACK,确认ack为收到的序号加一。

step3:第三次挥手
关闭服务器到客户端的连接,发送一个FIN给客户端。

step4:第四次挥手
客户端收到FIN后,并发回一个ACK报文确认,并将确认序号seq设置为收到序号加一。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

客户端发送FIN后,进入终止等待状态,服务器收到客户端连接释放报文段后,就立即给客户端发送确认,服务器就进入CLOSE_WAIT状态,此时TCP服务器进程就通知高层应用进程,因而从客户端到服务器的连接就释放了。此时是“半关闭状态”,即客户端不可以发送给服务器,服务器可以发送给客户端。
此时,如果服务器没有数据报发送给客户端,其应用程序就通知TCP释放连接,然后发送给客户端连接释放数据报,并等待确认。客户端发送确认后,进入TIME_WAIT状态,但是此时TCP连接还没有释放,然后经过等待计时器设置的2MSL后,才进入到CLOSED状态。

TCP机制(四大计时器)

重传计时器(Retransmession)

为了防止数据报丢失,当TCP发送一个报文时,就启动重传计时器,有2种情况:
1.若在计时器超时之前收到了特定报文的确认,则撤消这个计时器;
2.特定数据报在计时器超时前没有收到确认,则重传该数据报,并把计时器复位

持久计时器(Persistance)

死锁现象
要解开死锁,TCP为每一个连接使用一个持久计时器
当发送端TCP接收到rwnd=0的确认时,就启动持久计时器,当计时器截止时间到时,发送端TCP需要发送一个特殊的报文,叫做探测报文
该报文只有1字节,有序号,但无需确认
探测报文提醒接收端TCP:确认已丢失,必须重传
持久计时器截止时间设置为重传时间的数值,但是,如果没有收到从接收端回来的响应,则需要发送另外一个探测报文,并将持久计时器的值加倍和复位
如果结果和上面一样,发送端继续发送探测报文,直到其截止时间增大到阈值(通常为60s)为止
在这以后,发送端每60s发送一个探测报文,直到窗口重新打开

保活计时器(keep-alive)

在某些实现中要使用keeplive timer来防止两个TCP之间出现长时间的空闲
比如客户端打开了服务器端的连接,传送了一些数据,然后就保持静默了
也许该客户端除了故障,在这种情况下,这个连接就永远处于打开状态
保活计时器的解决方法为,当服务器端收到客户端的信息时,就把计时器复位,超时通常设置2小时
若服务器2小时还没有收到客户的信息,就发送探测报文
若发送10个同样的报文(每个相隔75s)还没有收到响应,就认为客户端出了故障,终止这个连接

时间等待(time-wait)

如果最后一个ACK报文丢失了,那么服务器TCP(它为最后的FIN设置了计时器)以为它的FIN丢失了,因而重传

TCP流控/拥塞管理

原理

接收端处理数据的速度是有限的,如果发送方的速度太快,就会把缓冲区u打满。这个时候如果继续发送数据,就会导致丢包等一系列连锁反应。
所以TCP支持根据接收端能力来决定发送端的发送速度。这个机制叫做流控制。

窗口大小
(接收端向发送端主机通知自己可以接受数据的大小,这个大小限制就叫做窗口大小)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值