如果本文对你有帮助,欢迎关注、讨论、点赞、收藏、转发给朋友,让我有持续创作的动力
⭐️⭐️这篇文章是一个我计算机网络复习的大汇总,参考了许多文章,也非常感谢大佬对我这篇文章的帮助,由于内容太多了我把它分成了上下两篇来写,这一篇将传输层协议TCP、UDP
以上是这篇文章的思维导图,个人建议复习的小伙伴都可以搞一个,方便自己复习用~
首先
详细的区别:
1、tcp是基于连接的,可靠性高;udp是基于无连接的,可靠性较低;
2、由于tcp是连接的通信,需要有三次握手、重新确认等连接过程,会有延时,实时性差;由于协议所致,安全性较高;而udp无连接,无建立连接的过程,因而实时性较强,安全略差;
3、在传输相同大小的数据时,tcp首部开销20字节;udp首部开销只有8个字节,tcp报头比udp复杂,故实际包含的用户数据较少。tcp无丢包,而udp有丢包,故tcp开销大,udp开销较小;
4、每条tcp连接只能是点到点的;udp支持一对一、一对多、多对一、多对多的交互通信。
应用场景的区别:
有状态;TCP会精准记录哪些数据发送了,被对方接受了,哪些没有,而保证数据按序到达,不允许差错 可控制;意识到丢包或者网络环境差,TCP根据具体情况调整自己的行为,控制自己发送速度或重发
而UDP不可靠原因:无状态,不可控
一次握手过程及变化、为什么不是两次、为什么不是四次、握手过程中可以携带数据吗、同时发起挥手会怎样
三次握手要确认双方的两样能力:发送能力与接收的能力。
最开始双方都属于CLOSED状态。然后服务器开始监听某个端口,进入LISTEN状态。
根本原因:无法确认客户端的接收能力。 可能出现的问题是,两次握手,服务端只要接收到然后发送相应的数据包,就 默认连接 了 ,但是事实上现在客户端可能已经断开连接了,这样也就带来了连接资源的浪费 ``
因为三次已经足够确认双方的发送和接收的能力了,四次以及四次以上当然就没必要啦
可以,但是只有第三次,此时的established状态相对安全并且够确认服务器的接收发送能力。
而不能在第一次握手携带数据是为了防止黑客在syn中放入大量数据造成服务器资源的消耗。
注意了,这个时候,客户端需要等待两个 MSL(Maximum Segment Lifetime,报文最大生存时间),在这段时间内如果客户端没有收到服务端的重发请求,那么表示 ACK 成功到达,挥手结束,否则客户端重发 ACK。
在发送方给接收方发SYN报文的同时,接收方也给发送方发SYN报文
上图就是解释同时打开情况下的状态变迁。
半连接队列、全连接队列、SYN Flood攻击过程、如何应对这种攻击
当客户端发送SYN到服务端,服务端收到以后回复ACK和SYN,状态由LISTEN变为SYN_RCVD,此时这个连接就被推入了SYN队列,也就是半连接队列。
当客户端返回ACK, 服务端接收后,三次握手完成。这个时候连接等待被具体的应用取走,在被取走之前,它会被推入另外一个 TCP 维护的队列,也就是全连接队列(Accept Queue)。
SYN Flood 属于典型的 DoS/DDoS 攻击。其攻击的原理很简单,就是用客户端在短时间内伪造大量不存在的 IP地址,并向服务端疯狂发送SYN。对于服务端而言,会产生两个危险的后果:
源端口、目标端口、序列号、ISN:ISN是如何计算的,为什么、确认号标记位窗口大小校验和可选项
如何标识唯一标识一个连接?答案是 TCP 连接的四元组——源 IP、源端口、目标 IP 和目标端口。
那 TCP 报文怎么没有源 IP 和目标 IP 呢?这是因为在 IP 层就已经处理了 IP 。TCP 只需要记录两者的端口即可。
复制代码
序列号在 TCP 通信的过程中有两个作用:
在 SYN 报文中交换彼此的初始序列号。
保证数据包按正确的顺序组装。
复制代码
即Initial Sequence Number(初始序列号),在三次握手的过程当中,双方会用过SYN报文来交换彼此的 ISN。
ISN 并不是一个固定的值,而是每 4 ms 加一,溢出则回到 0,这个算法使得猜测 ISN 变得很困难。那为什么要这么做?
如果 ISN 被攻击者预测到,要知道源 IP 和源端口号都是很容易伪造的,当攻击者猜测 ISN 之后,直接伪造一个 RST 后,就可以强制连接关闭的,这是非常危险的。
而动态增长的 ISN 大大提高了猜测 ISN 的难度。
复制代码
不要死记,只要有个印象就行
首轮三次握手、之后的三次握手、TFO优势
就是第二次握手的时候不是立即返回SYN+ACK了,
而是返回计算得到的`SYN cookie`,
放在TCP报文的Fast Open(快速打开)选项中,
客户端拿到cookie将其缓存
复制代码
首轮三次握手就是这样的流程。而后面的三次握手就不一样啦!
客户端发送Cookie+SYN+HTTP请求,
服务端验证合法,先确认,返回SYN+ACK,`返回HTTP响应`
客户端传ACK
复制代码
TFO 的优势
拿到Cookie验证通过就能返回HTTP请求了,
利用了1个往返时延`RTT`提前进行数据传输
复制代码
TFO 的优势并不在与首轮三次握手,而在于后面的握手,在拿到客户端的 Cookie 并验证通过以后,可以直接返回 HTTP 响应,充分利用了1 个RTT(Round-Trip Time,往返时延)的时间提前进行数据传输,积累起来还是一个比较大的优势。
TCP滑动窗口概念、流量控制过程
流量控制要做的事情,就是在通过接收缓存区的大小,控制发送端的发送。如果对方的接收缓存区满了,就不能再继续发送了。
具体是如何做的呢?举个例子:
慢启动、 拥塞避免、快速重传和快速恢复、基于丢包的拥塞控制点产生的问题--Google的BBR拥塞控制算法
是指目前自己还能传输的数据量大小;
接收窗口(rwnd)是接收端给的限制
拥塞窗口(cwnd)是发送端的限制 发送窗口大小 = min(rwnd, cwnd)
复制代码
采用一种保守的算法来慢慢地适应整个网路,这种算法叫慢启动;
过程: 1.首先,三次握手,双方宣告自己的接收窗口大小
2.双方初始化自己的拥塞窗口(cwnd)大小
3.在开始传输的一段时间,发送端每收到一个 ACK,拥塞窗口大小加 1,也就是说,每经过一个 RTT,拥塞窗口 翻倍。
如果说初始窗口为 10,那么第一轮 10 个报文传完且发送端收到 ACK 后,拥塞窗口 变为 20, 第二轮变为 40,第三轮变为 80,依次类推。直到达到慢启动阈值
达阈值后,如何来控制拥塞窗口的大小; 原来每收到一个 ACK,拥塞窗口加1,现在到达阈值了,拥塞窗口只能加: 1/拥塞窗口 以前一轮 RTT 下来,cwnd翻倍,现在cwnd只是增加 1 而已。
慢启动和拥塞避免是一起作用的,是一体的。
快速重传 如果发生了丢包,数据不是按序到达,接收端则重复发送之前的ACK 比如第5个包丢了,即使第6、7个包到达的接收端,接收端也一律返回第4个包的ACK。 收到 3 个重复的 ACK ,意识到丢包,马上重传; 选择性重传 ACK 报文SACK属性,通过left edge和right edge已经收到区间 快速恢复 发送端收到三次重复ACK之后,发现丢包觉得现网络已经有些拥塞了,会进入快速恢复阶段 发送端如下改变: 拥塞阈值降低为 cwnd 的一半、cwnd 的大小变为拥塞阈值、cwnd 线性增加
首先慢开始,拥塞窗口买次翻倍直到达到慢启动阈值,进入拥塞避免,拥塞窗口每次加一,遇到超时的情况进入快速重传,拥塞阈值降为拥塞窗口的一半,重新慢启动和拥塞避免,当再收到三个重复的ack时会进入块恢复阶段
联系客服