计算机网络之运输层 ---COOKIE

最新推荐文章于 2022-10-21 23:40:35 发布

Cookie@513

最新推荐文章于 2022-10-21 23:40:35 发布

阅读量313

点赞数 1

分类专栏：计算机网络文章标签：运输层计算机网络

本文链接：https://blog.csdn.net/weixin_42353390/article/details/101637215

版权

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

2 篇文章 0 订阅

订阅专栏

运输层:

网络层是为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

UDP：

在IP层的基础上增加了　分用和复用的功能（　利用端口号的不同来进行复用）　以及差错检验的功能；

特点: 不可靠

1. 不建立连接

2.不用回复确认

3.最大的优点,就是时延小速度快

UDP报文结构：

UDP数据校验：　二进制反码求和运算：

TCP :

面向连接的传输控制协议:

特点:具有可靠性;

1.可靠有序不丢不重;

2.TCP提供全双工通信

３.TCP面向字节流

5.TCP在发送时，根据对方给出的窗口值和当前的网络拥塞程度来决定自己发送窗口的大小;

TCP结构：

相关字段解释(对于理解TCP很重要)

序号: 在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，本字段表示本报文段所发送数据的第一个字节的序号，例如发送报文段1-2-3，则序号是1。
确认号: 期望收到对方下一个报文段的第一个数据字节的序号。若确认号为N,则证明到序号N-1为止的所有数据都已正确收到。例如 B 正确收到 A 发送来的一个报文段，序号为 301，携带的数据长度为 100 字节，因此 B 期望下一个报文段的序号为 401，B 发送给 A 的确认报文段中确认号就为 401；
数据偏移(首部长度) : TCP报文段的数据起始处距离TCP报文段的起始处有多远，以4B位单位，即1个数值是4B。
6个控制位。
- 紧急位URG : URG=1时，标明此报文段中有紧急数据，是高优先级的数据，应尽快传送，不用在缓存里排队，配合紧急指针字段使用；
- 确认位ACK : ACK=1时确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1；
- 推送位PSH : PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付；
- 复位RST : RST=1时，表明TCP连接中出现严重差错，必须释放连接，然后再重新建立传输链接；
- 同步位SYN : SYN=1时，表明是一个连接请求/连接接受报文；
- 终止位FIN : FIN=1时，表明此报文段发送方数据已发完，要求释放连接。
窗口：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。
检验和: 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在 TCP 报文段的前面加上 12 字节的伪首部。
紧急指针: URG = 1时才有意义，指出本报文段紧急数据的字节数；
选项: 最大报文段长度MSS、窗口扩大、时间戳、时间确认....；

TCP和UDP的区别

1、TCP面向连接（如打电话要先拨号建立连接）；UDP是无连接的，即发送数据之前不需要建立连接。
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付。
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流；UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）。
4、每一条TCP连接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通信。
5、TCP首部开销20字节；UDP的首部开销小，只有8个字节。
6、TCP的逻辑通信信道是全双工的可靠信道；UDP则是不可靠信道。

TCP连接：　３次握手:

步骤:

1)、A 向 B 发送连接请求报文段，SYN=1，ACK=0，选择一个初始的序号 seq = x；
2)、B 收到连接请求报文段，，如果同意建立连接，服务器为该TCP连接分配缓存和变量，向 A 发送连接确认报文段，SYN=1，ACK=1，确认号ack为 x+1，同时也选择一个初始的序号 seq = y (随机)；
3)、A 收到 B 的连接确认报文段后，为该TCP连接分配缓存和变量，同时还要向 B 发出确认，ACK = 1，确认号为 ack = y+1，序号为 seq = x+1(接上一开始的x)；(SYN = 0，因为只有在连接请求和连接请求接受的时候才会置为1)；
4)、最后，B收到A确认报文，状态变为ESTABLISHED(连接建立)，双方就可以进行双向通信了；

为什么TCP连接需要三次握手，两次不可以吗，为什么?

主要是 : 为了防止已失效的连接请求报文段突然又传送到了服务端，占用服务器资源 。(A是客户端，B是服务器)

现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到B。本来这是一个已失效的报文段，但是B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求。于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了。

由于现在A并没有发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据。B的许多资源就这样白白浪费了。

采用三次握手的办法可以防止上述现象的发生。例如在刚才的情况下，A不会向B的确认发出确认。B由于收不到确认，就知道A并没有要求建立连接。

3)、SYN攻击

SYN洪泛攻击发生在OSI第四层，这种方式利用TCP协议的特性，就是三次握手。攻击者发送TCP SYN，SYN是TCP三次握手中的第一个数据包，而当服务器返回ACK后，该攻击者就不对其进行再确认，那这个TCP连接就处于挂起状态，也就是所谓的半连接状态，服务器收不到再确认的话，还会重复发送ACK给攻击者。这样更加会浪费服务器的资源。攻击者就对服务器发送非常大量的这种TCP连接，由于每一个都没法完成三次握手，所以在服务器上，这些TCP连接会因为挂起状态而消耗CPU和内存，最后服务器可能死机，就无法为正常用户提供服务了。

2、TCP的连接释放: 四次挥手

数据传输结束后，通信的双方都可释放连接。现在 A 的应用进程先向其 TCP 发出连接释放报文段，并停止再发送数据，主动关闭 TCP连接。

A 把连接释放报文段首部的 FIN = 1，其序号 seq = u，等待 B 的确认。
B 发出确认(会送一个确认报文段)，ACK = 1，确认号 ack = u+1，而这个报文段自己的序号 seq = v(随机)。（TCP 服务器进程通知高层应用进程）
从 A 到 B 这个方向的连接就释放了，TCP 连接处于半关闭状态。A 不能向 B 发送数据；B 若发送数据，A 仍要接收。
当 B 不再需要连接时，发送连接释放请求报文段，FIN=1，ACK =1，seq = w(随机)，确认号ack = u + 1(为什么确认号是一样的，因为在这段时间内，A没有发送数据) (这时B进入LAST-ACK(最后确认阶段))。
A 收到后发出确认，ACK =1, seq = u + 1（因为FIN要消耗一个序号，所以从u+1开始），进入 TIME-WAIT 状态，等待 2 MSL（2*2 = 4 mins）时间后释放连接。
B 收到 A 的确认后释放连接。

四次挥手的原因

客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。

为什么A在TIME-WAIT状态必须等待2MSL的时间内？

MSL是Maximum Segment Lifetime英文的缩写，中文可以译为 “报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。2MSL = 2*2mins = 4mins 客户端接收到服务器端的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由： * 确保最后一个确认报文段能够到达B。如果 B 没收到 A 发送来的确认报文段，那么就会重新发送连接释放请求报文段，接着 A 重传一次确认，重新启动 2MSL 计时器。A 等待一段时间就是为了处理这种情况的发生。 * 等待一段时间是为了让本连接持续时间内所产生的所有报文段都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文段。

三次握手和四次挥手涉及的状态

三次握手

CLOSED：初始状态。
LISTEN：服务器处于监听状态。
SYN_SEND：客户端socket执行CONNECT连接，发送SYN包，进入此状态。
SYN_RECV：服务端收到SYN包并发送服务端SYN包，进入此状态。
ESTABLISH：表示连接建立。客户端发送了最后一个ACK包后进入此状态，服务端接收到ACK包后进入此状态。

四次挥手:

FINWAIT1：终止连接的一方（通常是客户机）发送了FIN报文后进入。等待对方FIN。
CLOSE_WAIT：（假设服务器）接收到客户机FIN包之后等待关闭的阶段。在接收到对方的FIN包之后，自然是需要立即回复ACK包的，表示已经知道断开请求。但是本方是否立即断开连接（发送FIN包）取决于是否还有数据需要发送给客户端，若有，则在发送FIN包之前均为此状态。
FINWAIT2：此时是半连接状态，即有一方要求关闭连接，等待另一方关闭。客户端接收到服务器的ACK包，但并没有立即接收到服务端的FIN包，进入FINWAIT2状态。
LAST_ACK：服务端发动最后的FIN包，等待最后的客户端ACK响应，进入此状态。
TIMEWAIT：客户端收到服务端的FIN包，并立即发出ACK包做最后的确认，在此之后的2MSL时间称为TIMEWAIT状态。

TCP的可靠传输和流量控制：

针对可靠传输和流量控制有三种协议: 停止等待协议、后退N帧协议、选择重传协议。

1、停止等待协议

停止等待协议也可以在传输层讨论。

停止等待协议是为了实现流量控制。

简言之: 就是每发送一个分组就停止发送，等待对方确认，在收到确认后再发送下一个分组。

主要分为: 无差错情况和有差错情况。

1)、无差错的情况

2)有差错的情况

缺点

信道利用率太低:

* 大部分时间都在路上；
* 即RTT（传输往返时延）太长；

后退N帧协议:

出现漏传的情况:

几个重点:

累积确认( 偶尔捎带确认)；
接收方只按顺序接收帧，不按序无情丢弃；
确认序列号最大的、按序到达的帧；
发送窗口最大为 2n - 1，接收窗口大小为1；

选择重传协议:

后退N帧协议的缺点 : 有些帧发送的好好的(由于exceptedSeqNum不对)，为什么让我重传呢?

解决办法:

设置单个确认，同时加大接收窗口，设置接收缓存，缓存乱序到达的帧。

基本方法:

特点:

对数据帧逐一确认，收一个确认一个(先来着不拒)；
只重传出错帧；
接收方有缓存；
W发送方 = W接收方 = 2 n-1；

发送方窗口大小的设置:

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

接收窗口只会对窗口内最后一个按序到达的字节进行确认:

例如接收窗口已经收到的字节为 {1, 2, 4, 5}，其中 {1, 2} 按序到达，而 {4, 5} 就不是，因此只对字节 {1, 2} 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

流量控制:

这个过程主机B进行了三次流量控制，第一次把窗口减小到rwnd = 300，第二次又减到rwnd = 100，最后减到rwnd = 0，即不允许发送方再发送数据了。

可能发生死锁的问题:

B 向 A 发送了零窗口的报文段后不久，B 的接收缓存又有了一些存储空间。于是 B 向 A 发送了 rwnd = 400 的报文段。但这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而 B 也一直等待 A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。为了解决这个问题，TCP 为每一个连接设有一个持续计时器 (persistence timer)。

TCP拥塞控制

1、拥塞控制原理

拥塞控制原理

在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生拥塞(congestion)。
出现资源拥塞的条件：对资源需求的总和 > 可用资源；
若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

拥塞控制: 防止过多的数据注入到网络中。

注意流量控制和拥塞控制的本质区别: 流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

rwnd : Receive Window，即接收窗口。接收方根据接受缓存设置的值，并告知给发送方，反映接收方容量。

cwnd: Congestion Window，即拥塞窗口。发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

接收窗口: 是接收方设置的。拥塞窗口: 是发送方设置的

拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。

TCP 主要通过四种算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

虽然 TCP 的窗口基于字节，但是这里按照窗口的大小单位为报文段来讨论。

发送的最初执行慢开始，令 cwnd=1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...

注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能也就更高。

设置一个慢开始阈值 (门限)ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。

如果出现了超时(最大拥塞窗口)，则令 ssthresh = cwnd/2，然后重新执行慢开始。

慢开始门限 ssthresh 的用法如下：

当 cwnd < ssthresh 时，使用慢开始算法。
当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法。
当cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法。

3、快重传和快恢复

思想: 发送方只要一连收到三个重复确认，就知道接收方确实没有收到报文段，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。

不难看出，快重传并非取消重传计时器，而是在某些情况下可更早地重传丢失的报文段。

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

注意:

发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，即应按以下公式确定：

发送窗口的上限值 = min {rwnd, cwnd} 当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值。当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值。