计算机网络-5.传输层

最新推荐文章于 2024-06-18 17:16:23 发布

want you tell me why

最新推荐文章于 2024-06-18 17:16:23 发布

阅读量125

点赞数

分类专栏：计算机网络文章标签： http

本文链接：https://blog.csdn.net/weixin_42655231/article/details/107622656

版权

计算机网络专栏收录该内容

4 篇文章 0 订阅

订阅专栏

比较好的题目

https://blog.csdn.net/ThinkWon/article/details/104903925?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.channel_param

1.传输层概述

2.UDP

3.TCP

4.TCP的连接管理

MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长的最长时间，超过这个时间报文将被丢弃;

TLL:我们都知道IP头部中有个TTL字段，TTL是time to live的缩写，可译为“生存时间”，这个生存时间是由源主机设置设置初始值但不是但不是存在的具体时间，而是一个IP数据报可以经过的最大路由数，每经过一个路由器，它的值就减1，当此值为0则数据报被丢弃，同时发送ICMP报文通知源主机。RFC793中规定MSL为2分钟，但这完全是从工程上来考虑，对于现在的网络，MSL=2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。TTL与MSL是有关系的但不是简单的相等关系，MSL要大于TTL

三次握手：

三次握手会导致SYN洪泛攻击：

四次挥手：

time_wait:

概念：

首先调用close发起主动关闭的一方在发送最后一个ACK之后，就会进入time_wait状态，会在等待2MSL之后关闭，

time_wait的原因

1）为了实现TCP全双工链接的可靠释放

假设客户端发的最后一个ACK丢失，由于TCP重传机制，服务端会重传FIN=1的报文，在client收到这个报文之前，客户端必须维护链接状态，直到收到FIN=1的报文，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态

2）使旧的数据包在网络中丢失

防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）

https://blog.51cto.com/10706198/1775555

从上图我们注意到，在TCP连接释放的过程中，从TIME_WAIT状态到CLOSED状态有一个超时设置，这个超时设置是2MSL（RFC793定义MSL为2分钟）,那么为什么在TIME_WAIT后必须等待2MSL时间呢？主要原因有两点（在我的上一篇博客中有讲，我们再来说下吧）：

1.为了保证客户端（我们记为A端）发送的最后一个ACK报文段能够到达服务器端。这个ACK报文段有可能丢失，因而使处在LASK—ACK端的服务器端（我们记为B端）收不到对已发送的FIN+ACK报文段。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME_WAIT状态不等待一段时间，而是在发送完ACK确认后立即释放连接，那么就无法收到B重传的FIN+ACK报文段，因而也不会再发送一次确认报文段，这样，B就无法正常进入CLOSED状态。

2.我们都知道，假如A发送的第一个请求连接报文段丢失而未收到确认，A就会重传一次连接请求，后来B收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。假如现在A发送的第一个连接请求报文段没有丢失，而是在某些网络节点长时间都留了，以至于延误到连接释放后的某个时间才到达B，这本来是已失效的报文段，但B并不知道，就会又建立一次连接。而等待的这2MSL就是为了解决这个问题的，A在发送完最后一个确认报后，在经过时间2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失，这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

大量的time_wait状态：

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻主动正常关闭连接。这个场景下会出现大量socket处于TIME_WAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。