没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
计算机网络基础
1.0、TCP 的三次握手和四次挥手
三次握手:
1. Client 将标志位 SYN 置为 1,随机产生一个值 seq=J,并将该数据包发送给 Server,Client 进入 SYN_SENT 状态,
等待 Server 确认。
2. Server 收 到 数 据 包 后 由 标 志 位 SYN=1 知 道 Client 请 求 建 立 连 接 , Server 将 标 志 位 SYN 和 ACK 都 置 为
1,ack=J+1,随机产生一个值 seq=K,并将该数据包发送给 Client 以确认连接请求,Server 进入 SYN_RCVD 状态。
3. Client 收到确认后,检查 ack 是否为 J+1,ACK 是否为 1,如果正确则将标志位 ACK 置为 1,ack=K+1,并将该数据
包发送给 Server,Server 检查 ack 是否为 K+1,ACK 是否为 1,如果正确则连接建立成功,Client 和 Server 进入
ESTABLISHED 状态,完成三次握手,随后 Client 与 Server 之间可以开始传输数据了。
四次挥手:
由于 TCP 连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发
送一个 FIN 来终止这一方向的连接,收到一个 FIN 只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是
在这个 TCP 连接上仍然能够发送数据,直到这一方向也发送了 FIN。首先进行关闭的一方将执行主动关闭,而另一方则
执行被动关闭。
1.数据传输结束后,客户端的应用进程发出连接释放报文段,并停止发送数据,客户端进入 FIN_WAIT_1 状态,此时客
户端依然可以接收服务器发送来的数据。
2.服务器接收到 FIN 后,发送一个 ACK 给客户端,确认序号为收到的序号+1,服务器进入 CLOSE_WAIT 状态。客户端
收到后进入 FIN_WAIT_2 状态。
3.当服务器没有数据要发送时,服务器发送一个 FIN 报文,此时服务器进入 LAST_ACK 状态,等待客户端的确认
4.客户端收到服务器的 FIN 报文后,给服务器发送一个 ACK 报文,确认序列号为收到的序号+1。此时客户端进入
TIME_WAIT 状态,等待 2MSL(MSL:报文段最大生存时间),然后关闭连接。
1.1、为什么要三次握手?为什么不是四次?
三次握手的原因:
三次握手可以防止已经失效的连接请求报文突然又传输到服务器端导致的服务器资源浪费。例如,客户端先发送了
一个 SYN,但是由于网络阻塞,该 SYN 数据包在某个节点长期滞留。然后客户端又重传 SYN 数据包并正确建立 TCP
连接,然后传输完数据后关闭该连接。该连接释放后失效的 SYN 数据包才到达服务器端。在二次握手的前提下,服务
器端会认为这是客户端发起的又一次请求,然后发送 SYN ,并且在服务器端创建 socket 套接字,一直等待客户端发送
数据。但是由于客户端并没有发起新的请求,所以会丢弃服务端的 SYN 。此时服务器会一直等待客户端发送数据从而
造成资源浪费。
为什么不是四次握手:
本来握手应该和挥手一样都是需要确认两个方向都能联通的,本来模型应该是:
1.客户端发送 syn0 给服务器
2.服务器收到 syn0,回复 ack(syn0+1)
3.服务器发送 syn1
4.客户端收到 syn1,回复 ack(syn1+1)
因为 TCP 是全双工的,上边的四部确认了数据在两个方向上都是可以正确到达的,但是 2,3 步没有上下的联系,
可以将其合并,加快握手效率,所有就变成了 3 步握手。
1.2、为什么要四次挥手?详解一下四次挥手的各步骤状态
因为当 Server 端收到 Client 端的 SYN 连接请求报文后,可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答
的,SYN 报文是用来同步的。但是关闭连接时,当 Server 端收到 FIN 报文时,很可能并不会立即关闭 SOCKET,所以
只能先回复一个 ACK 报文,告诉 Client 端,"你发的 FIN 报文我收到了"。只有等到我 Server 端所有的报文都发送完了,
我才能发送 FIN 报文,因此不能一起发送。故需要四步握手。
FIN_WAIT_1:
这个状态和 FIN_WAIT_2 状态都在再等待对方的回复,但是这两种状态是有区别的,FIN_WAIT_1 就是主
动 方 在 ESTABLISHED 状 态 的 时 候 , 想 要 主 动 关 闭 连 接 , 向 对 方 发 送 FIN 报 文 , 这 时 候 就 进 入 了
FIN_WAIT_1 状态。当他收到对方回复的 ACK 报文后,就进入了 FIN_WAIT_2 状态。 但是在实际操作中是很
难遇到 FIN_WAIT_1 状态的,因为无论对方是什么情况都应该立刻回应 ACK 报文,但是 FIN_WAIT_2 状态还
是可以在主动方中用 netstat 看到的。
FIN_WAIT_2:
上面已经对 FIN_WAIT_2 讲解过了,当主动方进入 FIN_WAIT_2 时,就表示着半连接状态,也就是主动
方还有数据要发给对方,这个数据就是之后的 ACK,所有他要等一会儿才关闭连接。
CLOSE_WAIT:
这个状态从表面也可以看出它的作用,就是等待关闭。当被动方接收到 FIN 时,会立刻回复一个 ACK 给
对方,接下来就是进入 CLOSE_WAIT 状态。在这个状态中,被动方需要考虑自己还有没有数据要发送给对方,
如果有可以继续发送,如果没有了就可以关闭连接了,发送一个 FIN 给对方。 这个状态其实也就是给自己一
个缓冲的时间,让自己处理完需要处理的事,然后去关闭连接。
TIME_WAIT:
这个状态就是一段时间后进行一些操作。当主动方收到了对方发来的 FIN 报文,并发出 ACK 报文,接下
来就等 2MSL 就可以进入 CLOSED 状态了。其实,如果主动方在 FIN_WAIT_1 状态下,收到了对方的
FIN+ACK 标志的报文,就可以跳过 FIN_WAIT_2 状态直接进入 TIME_WAIT 状态了。
LAST_ACK:
这个状态从表面不难不理解他的意思,这个状态就是被动方发送了 FIN 报文后,最后等待对方的 ACK 报
文,收到 ACK 报文后就可以进入 CLOSED 状态了。
CLOSED:
上面提到了几次这个状态,相比也猜出来了,这个状态表示的就是连接中断,已经关闭。
1.3、TCP 怎么保证可靠性?
(1)序列号、确认应答、超时重传
数据到达接收方,接收方需要发出一个确认应答,表示已经收到该数据段,并且确认序号会说明了它下一次需
要接收的数据序列号。如果发送发迟迟未收到确认应答,那么可能是发送的数据丢失,也可能是确认应答丢失,这
时发送方在等待一定时间后会进行重传。这个时间一般是 2*RTT(报文段往返时间)+一个偏差值。
(2)窗口控制与高速重发控制/快速重传(重复确认应答)
TCP 会利用窗口控制来提高传输速度,意思是在一个窗口大小内,不用一定要等到应答才能发送下一段数据,
窗口大小就是无需等待确认而可以继续发送数据的最大值。如果不使用窗口控制,每一个没收到确认应答的数据都
要重发。
使用窗口控制,如果数据段 1001-2000 丢失,后面数据每次传输,确认应答都会不停地发送序号为 1001 的应
答,表示我要接收 1001 开始的数据,发送端如果收到 3 次相同应答,就会立刻进行重发;但还有种情况有可能是
数据都收到了,但是有的应答丢失了,这种情况不会进行重发,因为发送端知道,如果是数据段丢失,接收端不会
放过它的,会疯狂向它提醒......
(3)拥塞控制
如果把窗口定的很大,发送端连续发送大量的数据,可能会造成网络的拥堵(大家都在用网,你在这狂发,吞
吐量就那么大,当然会堵),甚至造成网络的瘫痪。所以 TCP 在为了防止这种情况而进行了拥塞控制。
慢启动:定义拥塞窗口,一开始将该窗口大小设为 1,之后每次收到确认应答(经过一个 rtt),将拥塞窗口
*2。
拥塞避免:设置慢启动阈值,一般开始都设为 65536。拥塞避免是指当拥塞窗口大小达到这个阈值,拥塞窗口
的值不再指数上升,而是加法增加(每次确认应答/每个 rtt,拥塞窗口大小+1),以此来避免拥塞。
将报文段的超时重传看做拥塞,则一旦发生超时重传,我们需要先将阈值设为当前窗口大小的一半,并且将窗
口大小设为初值 1,然后重新进入慢启动过程。
快速重传:在遇到 3 次重复确认应答(高速重发控制)时,代表收到了 3 个报文段,但是这之前的 1 个段丢失
了,便对它进行立即重传。
然后,先将阈值设为当前窗口大小的一半,然后将拥塞窗口大小设为慢启动阈值+3 的大小。
这样可以达到:在 TCP 通信时,网络吞吐量呈现逐渐的上升,并且随着拥堵来降低吞吐量,再进入慢慢上升
的过程,网络不会轻易的发生瘫痪。
1.4、TCP 的拥塞控制
拥塞控制是防止过多的数据注入网络,使得网络中的路由器或者链路过载。流量控制是点对点的通信量控制,而拥
塞控制是全局的网络流量整体性的控制。发送双方都有一个拥塞窗口——cwnd。
1、慢开始
最开始发送方的拥塞窗口为 1,由小到大逐渐增大发送窗口和拥塞窗口。每经过一个传输轮次,拥塞窗口
cwnd 加倍。当 cwnd 超过慢开始门限,则使用拥塞避免算法,避免 cwnd 增长过大。
2、拥塞避免
每经过一个往返时间 RTT,cwnd 就增长 1。
在慢开始和拥塞避免的过程中,一旦发现网络拥塞,就把慢开始门限设为当前值的一半,并且重新设置 cwnd 为
1,重新慢启动。(乘法减小,加法增大)
3、快重传
接收方每次收到一个失序的报文段后就立即发出重复确认,发送方只要连续收到三个重复确认就立即重传(尽
早重传未被确认的报文段)。
4、快恢复
当发送方连续收到了三个重复确认,就乘法减半(慢开始门限减半),将当前的 cwnd 设置为慢开始门限,并
且采用拥塞避免算法(连续收到了三个重复请求,说明当前网络可能没有拥塞)。
采用快恢复算法时,慢开始只在建立连接和网络超时才使用。
采用慢开始和拥塞避免算法的时候
1. 一旦 cwnd>慢开始门限,就采用拥塞避免算法,减慢增长速度
2. 一旦出现丢包的情况,就重新进行慢开始,减慢增长速度
采用快恢复和快重传算法的时候
1. 一旦 cwnd>慢开始门限,就采用拥塞避免算法,减慢增长速度
2. 一旦发送方连续收到了三个重复确认,就采用拥塞避免算法,减慢增长速度
1.9、TCP 和 UDP 的区别和各自适用的场景
TCP UDP
TCP 是面向连接的传输层协议 UDP 无连接
点对点的两点间服务,一条 TCP 连接只能有两个端点 UDP 支持一对一,一对多,多对一,多对多的交互通信
可靠交付:无差错,不丢失,不重复,按序到达 尽最大努力交付,不保证可靠交付
有拥塞控制和流量控制保证数据传输的安全性 没有拥塞控制,网络拥塞不会影响源主机的发送效率
动态报文长度,即 TCP 报文长度是根据接收方的窗口大
小和当前网络拥塞情况决定的
面向报文,不合并,不拆分,保留上面传下来报文的边界
首部开销大,首部 20 个字节 首部开销小,8 字节。(源端口,目的端口,数据长
度,校验和)
TCP 和 UDP 适用场景
从特点上我们已经知道,TCP 是可靠的但传输速度慢,UDP 是不可靠的但传输速度快。因此在选用具体协议通信
时,应该根据通信数据的要求而决定。
若通信数据完整性需让位与通信实时性,则应该选用 TCP 协议(如文件传输、重要状态的更新等);反之,则使
用 UDP 协议(如视频传输、实时通信等)。
1.5、OSI 七层模型 TCP/IP 四层模型
OSI 七层模型:
物理层:
通过媒介传输比特,确定机械及电气规范,传输单位为 bit,主要包括的协议为:IEE802.3 CLOCK RJ45
数据链路层:
将比特组装成帧和点到点的传递,传输单位为帧,主要包括的协议为 MAC VLAN PPP
网络层:
负责数据包从源到宿的传递和网际互连,传输单位为包,主要包括的协议为 IP ARP ICMP
传输层:
提供端到端的可靠报文传递和错误恢复,传输单位为报文,主要包括的协议为 TCP UDP
会话层:
建立、管理和终止会话,传输单位为 SPDU,主要包括的协议为 RPC NFS
表示层:
对数据进行翻译、加密和压缩,传输单位为 PPDU,主要包括的协议为 JPEG ASII
应用层:
允许访问 OSI 环境的手段,传输单位为 APDU,主要包括的协议为 FTP HTTP DNS
TCP/IP 4 层模型包括:
网络接口层:MAC VLAN
网络层:IP ARP ICMP
传输层:TCP UDP
应用层:HTTP DNS SMTP
剩余16页未读,继续阅读
资源评论
五号说他没有小鱼干
- 粉丝: 1
- 资源: 3
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功