计算机网络——运输层

迷茫的羔羊羊

于 2023-05-20 17:03:58 发布

阅读量104

点赞数 1

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

本文链接：https://blog.csdn.net/m0_62565675/article/details/130783399

版权

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

23 篇文章 0 订阅

订阅专栏

8.TCP的运输连接管理——TCP的连接建立

8.1问题：可以为两次握手吗？

9.TCP的运输连接管理——TCP的连接释放

9.1问题：客户端为什么要等待2MSL？

10.TCP报文段的首部格式

1.概述

运输层的主要任务是为运行在不同主机上的应用进程提供通信服务，它屏蔽了下面的核心实现细节，使之看起来就像端对端的通信通道，运输层的两种协议：面向连接的TCP和无连接的UDP。

2.运输层端口号、复用与分用的概念

2.1端口号

运行在计算机上的进程使用进程标识符PID来表示。

TCP/IP体系的运输层使用端口号来区分不同的应用进程。

端口号使用16个比特组成，取值范围0~65535。

端口号有：熟知端口号，登记端口号，短暂端口号。

2.2复用和分用

需要注意的是UDP的协议字段为17位，TCP的协议字段为6位。

2.3应用层常用的运输层端口号

比如：用户通过DNS解析出来的IP地址通过HTTP协议来访问网站资源，用户发送的TCP报文封装为IP报文后发送给服务器，到达目的地后，TCP首部包含了源端口和目的端口，拿到目的端口，即可知道将数据载荷发送到哪个进程。

3.UDP与TCP的对比

UDP和TCP是运输层重要的两个协议。

3.1用户数据报协议UDP

无需连接
支持多种方式交互通信(一对一，一对多，...)
对应用层交付的报文直接打包
只是负责交付，即不可靠，不使用流量控制和拥塞控制
首部开销较小，仅需8个字节

3.2传输控制协议TCP

面向连接
每一个TCP连接只能有两个端点之间交互通信
面向的是字节流
可靠传输，使用流量传输和拥塞控制
首部最小20个字节，最大60个字节

4.TCP的流量控制

一般我们肯定是想尽快能的数据传输的更快些，但是，这便会产生一个问题，如果发送方把数据发送的过快，而接收方来不及接收的话，就会容易引起数据的丢失。

所谓的流量控制，就是指在接受方的调控下，让发送方的发送速率跟着自己走，要让接收方来得及接收，TCP接收方可利用自己的接收窗口大小来控制发送方的发送窗口大小。

分析上图——>当发送方的发送窗口被调控为0时，会启动一个持续计时器，当持续计时器超时后，发送方会发送一个零窗口探测报文，里面携带1字节的数据，顺便会启动一个零窗口探测报文的计数器，TCP规定就算接收方的窗口为0，但是零窗口探测报文是必定可以接收的，而且如果发送方的探测报文在传输过程中丢失了，这也无关紧要，因为如果零窗口探测报文计数器超时后，会继续发送零窗口探测报文，假如此时的接收方有缓存空间了，就会直接打破死锁的局面。

5.TCP的拥塞控制

若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就会变坏，比如在高速公路上行驶的车辆，如果一时期内涌入了太多的车辆，道路将变得拥堵，交通状况变差。网络中也是一样，若出现拥塞而不进行控制，那么网络的吞吐量就会随着负荷的增大而急剧下降。

TCP的拥塞控制分为：慢开始，拥塞避免，快重传，快恢复。

5.1慢开始

发送方会维护一个cwnd(拥塞窗口)，其值取决于网络的拥塞程度，并且会动态变化。

判断出现网络拥塞的依据，就是发送方没有按时收到接收方的确认报文。(发生超时重传)

发送方会将拥塞窗口当作发送窗口(swnd)。而且会维护一个慢开始门限(ssthresh)状态变量，当cwnd<ssthresh时，会使用慢开始算法，当cwnd>ssthresh时，会使用拥塞避免算法。

在使用慢开始算法时，每一次交互，都会使拥塞窗口成指数行增长，当拥塞窗口(cwnd)到达慢开始门限时(ssthresh)，便会使用拥塞避免算法。

5.2拥塞避免算法

当使用拥塞避免算法时，每一次交互，会使拥塞窗口的值增加1，注意此时只是缓解了拥塞的现象，并不是解决了拥塞，当拥塞窗口继续到达一定值时，可能会出现数据丢失，如果重传计数器超时，就会采取：

5.3快重传

有时，个别报文段会在网络中丢失，但是实际上网络并未发生拥塞，这就会导致发送方没有收到确认报文而误认为发生了拥塞。

快重传算法就是可以让发送方尽快知道个别报文段的丢失，尽快重传，而不是一直等超时重传器超时。

5.4快恢复

发送方一旦收到三个重复的确认，知道只是丢失了部分的报文段，而不是严重到拥塞的程度，所以就会执行快恢复的算法。

快恢复算法将慢开始门限(ssthresh)和拥塞窗口(cwnd)同时调整到当前拥塞窗口的一半，而直接开始进行拥塞避免算法。也有的快恢复算法是再调大一下拥塞窗口(cwnd)的值。

6.TCP超时重传时间的选择

超时重传时间的选择是TCP最复杂的问题之一,因为我们不能使用某次的RTT样本来计算超时重传时间RTO，

我们把从A发送报文段到A接收到B发送的确认报文段这一往返时间称为RTT。

而且往返时间RTT的测量也比较麻烦，例如：

针对出现超时重传的问题，karn提出了一个算法：在计算RTTS时，只要是发生了重传，那么就不采用其往返时间RTT样本。

但是这又会引起一个新的问题，比如说：某一时间段报文段的时延增大了很多，确实是发生了重传，但是我们又不把发送重传的报文段作为样本计算，那么超时重传时间不会发生变化，那么就会一直发生报文段重传。

所以karn算法需要改进一下：报文段只要发生了一次重传，那么就把超时重传时间增大2倍。

需要注意的是：当RTO4为64.3359时，RTT5明显超时了，所以发送了一次超时重传，而RTO5也变为了2倍的RTO4，如果还有RTO6的话，那么公式中旧的RTTs和RTTd会以RTTs4和RTTd4作为参考标准。

7.TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现数据的可靠传输。

需要注意的是，虽然发送方的窗口是随着接收方的窗口而变化的，但在同一时刻，发送方的窗口并不总是和接收方的窗口一样大。因为要传送窗口的值所以会时间滞后，而且发送方还可能根据网络的拥塞程度来调整发送窗口的大小。

对于接收到没有按序到达的数据会有两种结果：

1.直接丢弃，这样的话管理简单，但是这样对网络资源的利用较少。

2.先存储起来，等到所缺的字节收到之后，在一并交付给下一节。

TCP是全双工通信，通信期间任何一方时刻都在发送和接收数据，所以双方都会有发送窗口和接收窗口。

8.TCP的运输连接管理——TCP的连接建立

TCP连接建立要解决以下三个问题：

使TCP双方都能够确知对方的存在
使TCP双方能协商一下参数(例如：窗口大小)
使TCP双方能够对运输实体资源进行分配(例如：缓存大小)

ack = seq +SYN

注意：

TCP规定如果发送的报文段SYN=1，表示同步序列编号为1，则不携带任何数据，但是要消耗一个seq序列号。

TCP规定如果只有ACK为1，表示普通的确认报文段，如果不携带任何数据的话，则不消耗序列号(第三次握手是携带了数据的)。

8.1问题：可以为两次握手吗？

回答当然是不行，有以下三点原因：

三次握手才能阻止重复历史的连接(主要原因)

如果客户端发起一个连接请求，而正好客户端宕机了，那么客户端重启后，又会重新发送一个连接请求(两次的seq不一样)，但这种情况下旧的请求肯定会先到服务器，此时服务器接收后，给客户端发送一个确认报文段，服务器直接建立了连接，在这里如果是两次握手的话，那么此后服务器发送的数据全部是无效的，就造成了资源的浪费，等到客户端收到此确认报文之后，才会判断出来ACK不对，发送RST报文使服务器终止。那么如果是三次握手的话，就会避免这种事情的发生，就算服务器建立了连接，此时还缺少第三段报文，而客户端判断出来ACK不对，发送RST报文使得服务器连接断开，等待第二个连接请求报文的到来即可。
三次握手才能使双方同步对方的序列号

序列号在TCP连接中占据着重要的作用，序列号能够保证数据包不重复、不丢弃和按序传输，当客户端发送SYN+序列号的连接请求时，需要服务端回一个ACK的应答确认报文，表示客户端所发的报文已经成功接收，而此时服务端发送序列号时，也是需要客户端的应答报文的，显然二次握手并不能实现。
避免资源的浪费

两次握手下，因为服务器不知道自己的确认报文是否被收到，服务器会造成消息滞留情况下，服务器重复接受无用的连接请求SYN报文。