网络简略总结

本文深入探讨网络通信过程,包括TCP的三次握手与四次挥手,解释了为何需要四次挥手以及客户端的TIME_WAIT状态重要性。此外,文章还涉及OSPF、STP、链路聚合、网络资源统计、PXE中的DHCP工作原理,二至四层的转发原理,以及网络故障排查和OSI七层模型。
摘要由CSDN通过智能技术生成

目录

一、三次握手  四次挥手

1、三次握手:为了建立长链接进行交互即建立一个会话,使用http/https协议

2、四次挥手是一个断开连接释放服务器资源的过程

3、如果已经建立了连接,但是客户端突然出现故障了怎么办?

 4、谁可以中断连接?客户端还是服务端还是都可以?

5、TCP和UDP的区别

二、OSPF六类LSA与链路状态数据库

三、stp是什么作用,怎么操作

四、一般什么场景使用链路聚合

五、简述贵公司的PV、UV、IP,流量等资源大小?

六、PXE内DHCP工作原理

七、二层 三层 四层转发原理

八、物理交换机可以做什么?

九、网络通信五元组

十、网络故障排查简单思路

十一、OSI 七层模型


一、三次握手  四次挥手

1、三次握手:为了建立长链接进行交互即建立一个会话,使用http/https协议

:客户端产生初始化序列号s eq=x ,向服务端发送建立连接的请求报文,将 SYN=1 同步序列号;
:服务端接收建立连接的请求之后,产生初始化序号s eq=y ,并发送一个确认号(a ck=x+1) ,向客户端发送 建立连接的请求(SYN=1 ),确认客户端的数据 (ACK=1)
:客户端收到服务端的回复(a ck=y+1 ,包含收到请求,确认信号), ACK=1 ,确认客户端的数据,三次握手 成功

序列号 (seq):用来标识从计算机A发送到计算机B的数据包的序号,计算机发送数据时对此进行标记。

确认号(ack):表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。

控制位:描述了A B 两台电脑目前处于什么状态 ,分别为 URG、ACK、PSH、RST、SYN、FIN

URG(紧急位) 紧急指针(urgent pointer)有效。
ACK(确认位) 确认序号有效。
PSH(急切位) 接收方应该尽快将这个报文交给应用层。
RST(重置位) 重置连接。
SYN(同步位) 建立一个新连接。
FIN(断开位) 断开一个连接。

2、四次挥手是一个断开连接释放服务器资源的过程

  • 第一次挥手:客户端向服务器发送FIN报文(FIN=1,seq=u),发完后进入 FIN-WAIT-1 状态,即主动关闭TCP连接,不再发送数据,但可以接收服务器发来的报文,等待服务器回复
  • 第二次挥手:服务器接到FIN报文后,返回一个ACK报文(ACK=1,ack=u+1,seq=v),表明自己接收到此报文,服务器进入 CLOSE-WAIT 关闭等待状态,此时客户端就知道服务端接到自己的断开连接请求,进入到 FIN-WAIT-2 状态,TCP处于半关闭状态,但服务器端可能还有数据要传输。
  • 第三次挥手:服务器关闭客户端连接,发送FIN报文(FIN=1,seq=w,ack=u+1)给客户端,此时服务器处于 LAST-ACK 状态,等待客户端回应。
  • 第四次挥手:客户端收到FIN报文后,发送一个ACK(ACK=1,ack=w+1,seq=u+1)给服务器作为应答,此时客户端处于 TIME-WAIT 状态,这个状态是为了等待足够的时间以确保TCP接收到连接中断请求的确认。
  • 注意:这时服务器到客户端的TCP连接并未被释放,客户端需要经过等待2MSL(MSL表示一个报文的来回时间)后才会进入 CLOSED 状态,这样做的目的是确保服务器收到自己的ACK报文,如果在规定时间没有收到客户端发的ACK,那么服务器会重发FIN,客户端再次收到FIN报文,就知道自己的ACK丢了,然后会重发ACK给服务器。服务器收到ACK后,就会关闭连接,处于CLOSE状态了。

关于三次握手 和 四次挥手里的一些问题

为什么不能用两次握手进行连接?
        3次握手完成两个重要的功能,既要双方做好发送数据的准备工作 ( 双方都知道彼此已准备好 ) ,也要允许 双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
        现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S C 之间的通信,假定 C S 发送一个连接请求分组,S 收到了这个分组,并发 送了确认应答分组。
        按照两次握手的协定,S 认为连接已经 成功地建立了,可以开始发送数据分组。可是,C S 的应答分组在传输中被丢失的情况下,将不知道 S 是否已 准备好,不知道S 建立什么样的序列号, C 甚至怀疑 S 是否收到自己的连接请求分组。在这种情况下, C 认为连接 还未建立成功,将忽略S 发来的任何数据分 组,只等待连接确认应答分组。而 S 在发出的分组超时后,重复发 送同样的分组。这样就形成了死锁。
为什么 TIME_WAIT 状态需要经过 2MSL( 最大报文段生存时间 ) 才能
返回到 CLOSE 状态?
  1. 防⽌客户端最后⼀次发给服务器的确认在⽹络中丢失以⾄于客户端关闭,⽽服务端并未关闭,导致资源的浪费。
  2. 等待最⼤的2msl可以让本次连接的所有的⽹络包在链路上消失,以防造成不必要的⼲扰。

客户端为什么会要有 TIME-WAIT 状态:

  1. 如果最终的ACK丢失,服务器会重发FIN,客户端必须维护TCP状态信息以便可以重发最终的ACK,否则就发送RST(TCP连接出错),结果服务端认为发生错误。
  2. TCP实现必须可靠地终止连接的两个方向(全双工关闭),客户端必须进入TIME_WAIT状态,以免可能出现重发ACK的情形。

为什么连接的时候是三次握手,关闭的时候却是四次握手?
        因为握手的时候并没有数据传输,所以服务端的   SYN 和 ACK 报文可以一起发送 ,但是挥手的时候有数据在传输,所以 ACK 和 FIN报文不能同时发送,需要分两步,所以会比握手多一步。

为什么三次挥手不行
        因为服务端在接收到FIN, 往往不会立即返回FIN ,必须等到服务端所有的报文都发送完毕了,才能发FIN。因此先发一个ACK表示已经收到客户端的FIN,延迟一段时间才发FIN。这就造成了四次挥手。

        如果是三次挥手会造成:

        如果将服务端的两次挥手合为一次,等于说服务端将ACK和FIN的发送合并为一次挥手,这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端,从而让客户端不断的重发FIN。所有只能第二次握手先发送ACK确认接收到了客户端的数据,等服务器发送完了数据,再发送FIN包进行第三次挥手。

3、如果已经建立了连接,但是客户端突然出现故障了怎么办?

        TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每 收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2 小时,若两小时还没有收到客户端的任 何数据,服务器就会发送一个探测报文段,以后每隔75
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值