计算机网络-浅谈运输层(传输层)

还很菜的猴子

墨衍会员 · AI 创作全网分发码龄7年

关注

原创最新推荐文章于 2026-07-07 11:51:02 发布 2k 阅读 AI 写同款· GEO 优化 ›

运输层协议和网络层协议的主要区别文章主要介绍了运输层协议和网络层协议的主要区别立即下载

(记录学习,有误请一定告知)

什么是运输层

运输层在OSI七层协议中为第4层(在网络层的上层,会话层的下层),在TCP/IP协议中为第三层(网络层上层,应用层下层),其功能就是给予不同主机间的应用进程提供分组通信,主要的通信协议为UDP和TCP。

为什么需要运输层

从网络层的角度来说,IP数据报的首部明确了两个要通信的主机的地址,并能够将分组数据由发送端主机传送到目的主机端中,实现两台主机间的通信,既然都已经实现了两台主机间的通信那为什么还需要运输层呢? 其实 “两台主机通信” 并不够准却,应该是 “两台主机的应用进程间通信” ,因此IP做的仅仅是将分组数据传送到了目的端主机的网络层中并没有交付到目的主机的进程中,而运输层就是将在网络层中的分组数据交付给应用层达到应用进程间通信的作用。

说了这么多可以总结两句话:
网络层:为主机间提供逻辑通信

传输层:为主机中的应用进程提供逻辑通信

在这里插入图片描述

运输层的分用与复用

上面说到对于运输层而言,所谓的通信是指两台主机间的应用进程间的通信,而不是两台主机间的通信,那么两台主机间不会在一个时刻只相互通信一个进程的数据吧!一定是多个进程与多个进程之间同时的交互,因此,运输层有一个很重要的功能---- 分用和复用

举个平常的例子:
当一个小区的sf快递小哥收到这个小区所有业主要寄出的sf快递,之后把快递都交到sf的物流中心,这个行为我们就可以说是小区的所有业主复用了小区的快递小哥,而当各地方的sf物流中心包裹要寄来这个小区时,快递小哥收集了包裹后分别的交给对应的业主,这个行为就是分用。

而在运输层中,应用层的所有应用进程从端口将数据通过运输层传输到网络层,这就是复用,而运输层收到从网络层要发送给各应用进程的数据后,运输层通过端口号将分别交付到指定的应用进程这就是分用

端口号

1. 什么是端口号

上面说到的端口,端口号就是应用层中各个应用进程的一个号码,端口就像一扇门,在发送端,应用进程通过端口将要交互的数据传给运输层;而在接收端运输层通过端口号将数据传给个应用进程

2. 端口号分类

2.1 服务器端口号:
　　　熟知端口号(系统端口号):数值为 0-1023,详细的对应可在IANA查询
　　　登记端口号:数值为 1024-49151,可在IANA登记办理

常见的熟知端口号
　　　　　　　　　　　　　　　　　

2.2 客户端口号: 数值为 49152-65535,又叫短暂端口号,当客户端和服务器端的通信结束时,
　　　　　　　客户端口号就会消失

##注意##端口号的作用范围只在本地,在整个因特网中,不同计算机的相同端口号是没有关联的

无连接服务和面向连接服务

所谓的连接指两端在数据传前是否需要建立连接,而面向连接就是在通信之前,必须建立连接,在通信的过程中,会一直被监控和管理,在通信结束后,释放连接;而相对于面向连接,无连接服务就是两个通信设备通信前不建立连接,当要传数据时,直接把数据放到网络上,由系统决定怎么传输数据,无连接服务不能保证数据发送端发送的数据顺序以相同的顺序到达接收端

UDP(用户数据报协议)

1. 特点

1.1 UDP是无连接的:字面上的意思,UDP在发送数据之前不用建立连接(此处可和后面讲到的TCP建立连接做对比)

1.2 UDP的服务是尽最大努力的服务:就是不可靠的服务,说的在白话一些就是UDP传送的数据不会保证有没有传到,也不会确认到底传到没有,但UDP有简单的差错检验,不过如果检验出错误,会直接丢弃报文所以主机不需要维持连接状态表(节省资源)

1.3 UDP没有拥塞控制:所以使用UDP传输时当网络出现拥塞时,并不会影响发送端的发送数据,所以对于实时应用要求高的应用进程(视频电话、直播)会使用UDP

##注意##虽说实时应用要求高的应用进程会使用UDP,但当很多这类应用进程同时向网络发送数据时,网络就可能会引起拥塞,会造成所有应用进程都没法正常使用##

2. UDP首部格式

2.1 每个UDP的数据报有两段格式=>UDP首部+UDP数据部份

2.2 UDP首部:源端口+目的端口+长度+校验和 (每一个字段占用2字节)

源端口: 需要对方回信时选用,不需要时可以是全0
目的端口: 在终点交付报文时必须使用
长度: 就是数据报长度,最小为8
校验和: 检测数据报在传输中是否有错,有错就扔

##如果目的端UDP发现目的端口号并没有对应的应用进程,则会丢掉数据报,并由ICMP回传
"端口不可达"差错报文给发送方

TCP(传输控制协议)

1. 特点

1.1 TCP是面向连接的运输层协议: 应用程序再使用TCP协议前必须建立TCP连接,传送完数据后,释放TCP连接

1.2 每一条TCP连接只能是点到点(一对一的套接字)的连接

##注意##端口号拼接到IP地址后就是套接字,每一条TCP的连接的两个端点是套接字,
TCP ={socket1 , socket2} ={(IP1:port1 . IP2:port2)},

1.3 TCP提供全双工通信: TCP允许通信的应用进程双方都能够随时传送数据,连接的两端都设有发送缓存和接收缓存

1.4 面向字节流: 虽然应用进程和TCP交互的是一次一个数据块,但TCP把应用进程交付下来的数据块视为没有意义的字节流,TCP并不明白每一个数据块的含义,也不保证接收方应用程序所接收到的数据块和发送方传送的数据块有大小对应的关系(会根据对方TCP的窗口值和网络拥塞的程度来决定一个报文含有多少字节),但接收方收到的字节流和发送方收到的字节流是一样的

2. TCP报文首部格式

废话不多说直接上格式,文字对应着图片看
在这里插入图片描述
TCP报文段 = TCP首部+TCP数据, TCP首部代表着TCP的全部功能,和该TCP报文段的状态

(1) 源端口、目的端口: 2字节,就是源端口号和目的端口号,同UDP的作用一样,TCP分用就是通过端口来实现的

(2) 序号: 4个字节,(序号的值为0 ~ 2^32-1),代表着该TCP报文段中发送数据的第一个字节的序号,TCP是面向字节流的,所以每个字节的序号是连续的

例如:TCP序号为100代表发送数据的第一个字节为101,而该数据报文段总共发送100个字节,最后一个字节的序号就是200,下一个数据报文段的数据开始字节就是201

(3) 确认号: 4个字节,代表期望对方下一个报文段的第一个数据字节的序号,从上面的例子可以知道,此例子中的TCP报文首部的确认号就是201

(4) 数据偏移: 占4位 ,代表着报文段首部的长度,其记录着TCP报文段的首部位置到TCP报文段数据起始处的距离

(5) 保留位: 占6位,保留以后使用,现在要至为0

接着是6个控制位,又叫标志位,说明本报文段的状态性值
#######
(6) URG(紧急): URG=1时,紧急指针有效,代表该报文段是紧急的报文段,系统会有先传这一报文段,不会按原来顺序传送(相当于有较高优先级)

(7) ACK(确认): 只有当ACK=1时,确认号才有效,TCP规定所已建立连接的TCP,ACK都必须标志为1

(8) PSH(推送): 当接收方收到PSH=1的报文段时,会尽快的将该报文段交付给对应的应用进程,而不会等到缓存满了在一起发送

(9) RST(复位): 当RST=1,代表TCP连接出现了严重的差错,系统会释放TCP连接再重新建立TCP连接,RST=1也会用来拒绝非法的TCP报文段或者拒绝打开一个链接

(10) SYN(同步): 代表建立连接时的同步序号,SYN=1,ACK=0时代表这个报文段是一个连接请求报文段;SYN=1,ACK=1代表这个报文段是一个接受请求的确认报文段

(11) FIN(终止): FIN=1代表数据已经发送完毕,释放连接
#######

(12) 窗口: 占2字节,(数值为0 ~ 2^16-1),是代表发送此报文的告知接收此报文的,从报文段首部的确认号算起,我还能接收多少数据,有点绕口其实窗口值就是,发送的那一方告诉接收的那一方,我还可以接收多少字节的数据

(13) 检验和: 占2字节,用来差错检验

(14) 紧急指针: 当URG=1时有效,代表紧急数据的字节数,所有紧急数据处里完,进程就会恢复正常操作

(15) 选项: 最长为40字节,为了满足TCP报文段字节数为4的倍数

##以下的内容都以单端为讲解,但实际上,TCP是全双工通信,接收方也是发送方,发送方也是接收方##

3. 可靠传输

3.1 可靠传输特点:

3.1.1 不错: 数据不会出差错
3.1.2 不丢: 数据不会丢失
3.1.3 不乱: 数据按造发送端发送的数据顺序以相同的顺序到达接收端

4. 可靠传输工作原理

TCP的报文是要下交给IP层传送的,但IP层的做的工作是尽最大努力的服务,是不可以靠的传输服务,所以TCP要使用一些方法满足可靠传输。
理想的传输条件1.传输信道不产生差错 2.不管发送方发送的多块.接收方都能够来得及处里接收的数据, 然而现实总是差强人意,这种理想是不存在的,因此使用一些可靠传输的协议,可以达成上面两个条件

4.1 停止等待协议: 就是当发送方传送数据到接收方,接收方能够回传确认信息给发送方,发送方收到后再接着传接下来的数据分组,但在发送和接收通信时往往会有以下情况发生 :

4.1.1无差错情况:这是最理想的情况了,就是发送端发送的数据分组都能够到达接收端,并且接收端也都可以回传确认信息
在这里插入图片描述

4.1.2分组出现差错或丢失 :指得是传送端将数据传送给发送端后,接收端检测数据是有差错的或者压根数据在传输过程丢失,这时接收端会丢弃数据分组,接着啥也不干,而发送端一直没收到接收端的确认信息,则重新在发送一次相同的数据分组,这个过程叫做超时重传, 要达到超时重传需要:

a. 设置一个超时计时器并且这个计时器的设计需要设计成比分组传输的平均往返时间更长,并且在接收到确认分组后,这个超时计时器就会丢失
b. 发送端必须暂时保留发送的数据分组的副本,直到接收端回传确认信息再丢弃
c. 分组和确认分组都要编号,这样才可以确认哪些数据分组已经有回传确认了哪些没有

图片来源:https://www.cnblogs.com/kikochz/p/13559707.html

4.1.3确认丢失或迟到: 从字面意思就可以知道,发送端的分组数据到达接收端并没有丢失且没有差错,但接收端返回确认信息时,确认信息丢失或迟到,导致发送端以为是数据没有传到,因此再传了一次,导致接收端收到重复的分组,这时接收端会做:

a. 将重复的数据丢弃
b. 再重新传一次确认信息; 而发送端会一直等待确认,如果一直没等到就一直等
c. 如果是迟到的情况,其实很简单,就是把重复的确认给丢弃掉就行了
在这里插入图片描述
图片来源:https://www.cnblogs.com/kikochz/p/13559707.html

上述的这种可靠传输协议又称为ARQ(自动重传请求),而使用ARQ就可以满足在不可以靠的传输网络上实现可靠的通信

4.2连续ARQ协议: 从停止等待协议可以得出,停止等待的效率是非常低的,因为分组在信道中往返的时间,占整个分组传输到确认的时间太大,而往返的这段时间,信道又是空闲的,解决这个办法就是使用流水线传输,发送端不等到确认回传才发送,而是发送端连续发送多个分组数据,这样就可以大大提高信道的使用率,而使用流水线传输就要使用连续ARQ协议+滑动窗孔协议来完成

4.2.1 基本概念:发送方会维持一个发送窗口,在发送窗口内的分组可以连续发送出去,接收方采用的是累积确认方式,累积确认就是接收方会对按序到达的最后一个分组发送确认,代表这个序号之前的所有分组我已经确认收到了
在这里插入图片描述

4.2.2 连续ARQ的缺点: 假设今天的发送窗口大小为5,而序号4的分组丢失了,因此接收方回传了序号3的确认,这时发送不知道序号5是否也是丢失了或者差错(就算序号5到达了),也会将4、5两个序号分组重新都发出,这种现象叫做Go-back-N,表示要退回来重传已发送过的N个分组。

5. 可靠传输的实现

5.1 滑动窗口以字节为单位: 假定发送端A收到接收端B发送来的确认报文段,窗口值20,确认号31,这时A就会开辟一个序号31-50的发送窗口,再没有收到B的确认之前,A都可以连续的将窗口的分组发送出去,但只要是发送过的数据,都必须保留副本在发送缓存中,以防数据丢失或差错,要超时重传的时后使用,副本直到收到B的确认报文段才抛弃。

5.1.1 发送窗口中的序号代表可以发送的序号,发送出口后沿的后面,代表已发送且已确认分组,发送前沿的前面代表不允许发送的分组,以下介绍发送窗口发生大小变化的情况:

后沿前移: 首先后沿是不能后移的,因为不能收回已经确认过的分组,当A接收到B传来的确认序号后,则后沿就到该位置,不然是不会移动的

前沿不动: 通常是会一直向前移动的,但当 1. 没有收到确认,并且接收放也没有更改窗口大小 2.接收到确认,但窗口值变小

前沿后移: 首先这是TCP不赞成的方式,会发生这种情况就是因为接收端通知窗口缩小,但不建议的原因是因为当发送端收到窗口缩小的信息时,可能已经把原发送窗口的数据传出去了。
在这里插入图片描述
图片来源:
https://wenku.baidu.com/view/bff09826a36925c52cc58bd63186bceb19e8edfa.html

5.2 深入发送窗口:我们可以看到有三个指针p1,p2,p3,这三个
详细参图,其中要注意的是p3-p2

5.2.1 可用窗口: 可用窗口为p3-p2,代表的是允许发送的分组但还未发送的数据字节数

5.2.2 同第4点所讲到的,接收端口B回传确认分组采用累积确认的方式回传确认,因此,当B接收到序号32,33的序号,并没有收到31的分组时,是不会传送32或33的确认,B依旧会回传确认31给发送端,并且将32,33缓存在接收缓存中
在这里插入图片描述
图片来源:
https://wenku.baidu.com/view/bff09826a36925c52cc58bd63186bceb19e8edfa.html

5.2.3发送窗口的移动以及可用窗口的改变:
从图可以看到假定现在B收到了33以前的分组,并回传了34的确认号,那么发送端的发送窗口后沿就会想前到34(接收端的接收窗口后沿也是会到34),这时发送窗口前沿也会像前到53,但还没有收到42的确认号,此时,发送端的可用窗口就会增加,发送端可以在将可用窗口的数据发送。

在这里插入图片描述

当发送端发送了到53以前的分组,但仍然没有收到确认号时,此时可用窗口为0,发送端会一直等到收到B的确认才改变发送窗口的后沿前沿位置

##如果一直没有收到B的确认怎么办?##
如果确认在传输中丢失或者接收端就没有收到分组数据或分组数据有错,当达到超时计时器的时间后,A就会启动超时重传机制,重传发送窗口的分组
在这里插入图片描述
图片来源:
https://wenku.baidu.com/view/bff09826a36925c52cc58bd63186bceb19e8edfa.html

5.3发送缓存和接收缓存:
前面说过TCP连接是面向字节流的,在发送端应用进程把字节流写入TCP的发送缓存,在接收端,应用进程从运输层接收字节流,并写入TCP接收缓存

发送缓存存放:
a. 发送应用进程写入TCP准备发送的数据分组
b. TCP已经发送出的分组但未收到确认的数据

接收缓存存放:
a. 按序道达,接收应用进程还没来得急读取的数据
b. 接收端从发送端接收来的没有按序到达的分组数据

在这里插入图片描述
图片来源:
https://wenku.baidu.com/view/bff09826a36925c52cc58bd63186bceb19e8edfa.html

##发送窗口的后沿和发送缓存是重合的,已经确认的数据就会被丢弃删除##

##如果分组检测出有差错会丢弃分组,如果应用进程来不及读取分组数据,接收缓存就会被填满##

##发送端的发送窗口虽然是依据接收端的TCP报文段中的窗口去构造的,但不代表和接收端的窗口是一致的,发送端会考虑如网络拥塞等实际问题去构造发送窗口##

##对于没有按序到达接收端的分组数据,TCP没有明确规定该如何处哩,但大部份都会先暂时存在缓存中##

##接收端明确规定累计确认机制,延迟传送确认的时间为0.5秒##

6. TCP流量控制

6.1目的: 总的来说都会希望数据传的快一些,可是当发送方的数据过快,导致接收方来不急接收,就会造成数据丢失,流量控制就是防止这个状况,抑制发送方的传送速率,而滑动窗口就是我们来实现流量控制的机制

6.2持续计时器: 发送方的发送窗口是不能大于接收方的接收窗口的,这样会造成一个情况,发送方的所有发送窗口的分组都送出去,而接收方的接收窗口也满了,这时接收方就会传送零窗口值的报文段,这时发送端就不再发送,而过一段时间,接收端口的应用进程接收完接收端口的数据后,接收端回传一个不为0的窗口值确认给发送端,但不幸的是,确认丢失了,因此防止这种状况,TCP的一方接收到窗口0的报文段时,会启动持续计时器,计时器时间到了,就会传送一个零窗口的探测报文段(只有1字节),如果回传的确认仍然是0窗口那么计时器重新计时,如果收到窗口不为0,那么就可以打破这个僵局

6.3 Nagle算法: 现在有一个例子: 用户只发送了1个字节的数据在到达接收端前这个数据必须加上1.TCP首部(这样就变成21字节)2.IP首部(这时已经41字节),接收方接收到后回传40字节的确认报文段,如果后续用户又要求回传这一字节的话那么可以看出,仅仅一个字节但却占用了80-160个字节,可想而知效率是非常低的,而Nagle算法就是解决这个问题

6.3.1 Nagle算法实现: 如果发送进程要一个一个字节写到发送缓存的话,那么发送TCP就会先把第一个字节先传出去,等到收到接收方的确认时在一次把缓存给送出去,并继续缓存数据直到收到前一个报文段的确认在继续发送缓存的报文段

6.3.2 湖涂窗口综合症: 主要是因为接收方应用进程一次只从接收缓存接收一个字节的数据,并将确认发给发送方,这样一来网络的效率就会变得很低,解决这个问题有以下两个方法:

1.让接收方等待一段时间,使接收缓存有能力接收一个最长的报文段在发送确认

2.等到接收缓存有一半的空闲

7. TCP拥塞控制

7.1 拥塞定义: 对资源的需求总和>可用资源总和,当这个式子成立时则发生拥塞

7.2拥塞控制vs流量控制:

拥塞控制: 拥塞控制面向的是整个全局的,是防止过多的数据注入到网络中,使网络中的路由器或者其他数据链路节点不会发生过载

流量控制: 流量控制更多的是面向点到点的通信量控制,是端到端的问题

7.3 TCP的拥塞控制方法: 分四种 1. 慢开始 2. 拥塞避免 3. 快重传 4. 快恢复

拥塞窗口(cwnd): TCP的拥塞控制也是基于窗口的拥塞控制,发送方会维持一个拥塞窗口,发送方的发送窗口等于拥塞窗口,拥塞窗口的大小取决于网络中的拥塞程度

慢开始: 当主机开始发送’数据时,因不清楚整个网络的负荷量,所以有小到大慢慢增加发送窗口
初始为:

当SMSS(发送方最大报文段)>2190字节: cwnd= SMSS*2字节,且不得超过2个报文段
当SMSS>1095: cwnd=SMSS*3,且不得超过3个报文段
当SMSS<=1095: cwnd=SMSS*4,且不超过4个报文段

##慢开始规定,每当收到一个确认后,拥塞窗口则增加一个SMSS数值##

从图中可以看出,每当经过一个传输轮次(即分组数据报文段往返时间RTT),cwnd的大小就会加倍

在这里插入图片描述
慢开始门限(ssthresh): 那难道拥塞窗口就会这样无止尽的增长吗?当然不是,发送端还会维持一个慢开始门限,当:
cwnd<ssthresh: 使用慢开始算法
cwnd=ssthresh: 可用慢开始或拥塞避免
cwnd>ssthresh: 使用拥塞避免

拥塞避免: 使cwnd更缓慢的增加,当每经过一个传输轮次,cwnd只增加1

根据下图TCP拥塞窗口cwnd在拥塞控制的变化情况,来说明整个TCP拥塞控制的过程

一、拥塞窗口初值为1,ssthresh初值为16,TCP建立连接,发送端进入慢开始阶段直到(1)的位置,发送端进入拥塞避免当到(2)时网络出现超时,此时发送端认为是网络拥塞(此时cwnd=24)

二、当发送端认为是网络拥塞时,更改ssthresh=cwnd/2=12,发送端拥塞窗口为1,重新进入慢开始状态,一直到拥塞窗口为12,再次进入拥塞避免,一直到(4)此时发送端收到3个相同的确认,这时就会进入快重传的阶段

三、快重传: 当发送方发送的1,2报文段和4,5,6报文段都到达接收方,但可是,3报文段在过程中丢失或出差错,此时,为了防止发送端一直没有收到3的确认以为是网络超时又回到慢开始导致网络运行效率降低,会出现以下的情况 a.收到2号报文段回传对2号报文段的确认,不同于流量控制中的累积确认机制,拥塞控制的快重传在收到4号报文段马上回传2号报文段的重复确认,5,6号报文段同4号报文段,这时发送端连续接收到3个相同的重复确认(不含最一开始的确认),发送端就会知道3号报文段丢失或差错,这时就会立即重传3号报文段

四、快恢复: 即图中(5)的地方,发送方知道这个丢失的现象并不是超时,所以发送方不会再进入到慢开始的阶段,而此时的窗口值(16),发送方重新设定ssthresh为16/2=8,拥塞窗口也变为8,进入拥塞避免阶段继续传输
在这里插入图片描述

7.4 AIMD算法: 从刚刚的过程可以看到当网络超时或者发送方收到三个重复确认,门限值(ssthresh)变为当时拥塞窗口的一半,并减小拥塞窗口的数值,这种称为乘法减小(MD),而在拥塞避免,拥塞窗口按现行规律增大,这称为加法增大(AI)=>加起来就是AIMD

7.5 TCP的全局同步: 首先这是一个不好的现象,因为ip的尾部丢弃策略(就是当ip队列已满,则ip抛弃尾部新进的报文段),导致TCP发送端以为是网络发生拥塞,进入了拥塞控制,然而在一个时刻的一个网络中不会只有一个TCP连接,所以影响了多个TCP,此时网络中的TCP都同时进入了拥塞控制的慢开始,导致网络的通信量下降很多,解决这个方法就是建立一个AQM(主动队列管理)

7.6 AQM(主动队列管理): 就是不等到路由器的队列已满时才开始丢弃报文段,而是先设定一个值,当队列中的报文段到达这个数值是就开始预先主动的丢弃到达的报文段,这样就可以优先的让发送方放慢传输的速率

8.TCP的连接建立(3次握手)

(1) 首先,两方都是CLOSED状态,客户端优先打开连接,服务端被动打开连接

(2) 接着,服务器端率先创建TCB(传输控制模块),准备接受客户端的连接请求,状态变为LISTEN

(3) 客户端也先创建TCB,当要开始建立连接时向服务器端发送请求报文(第一次握手)

(4) 第一次握手: 客户端向服务器端发送连接请求报文段,这时TCP首部的同步标志位(SYN)=1,同时选择一个序号seq=x,并进入到SYN_SENT(同步已发送)状态 ##TCP规定: SYN报文段(就是SYN=1)不可以携带数据,但消耗一个序号##

(5) 第二次握手: 服务器端接收到客户端的请求报文后,如果同意连接,则回传一个SYN=1,ACK=1,确认号ack=x+1,同时也选择一个初始序号seq=y的确认连接报文段,进入SYN_RECV(同步收到)这个确认报文段也不能携带数据但必须消耗一个序号

(6)第三次握手: 客户端接收到服务器端的确认连接报文后,像服务器端发送确认报文段,ACK=1,ack=y+1,序号seq=x+1,其中ACK报文段是可以携带数据的,如果不携带则不消耗序号,如果携带则下一个数据序号仍然是seq=x+1,此时客户端进入ESTABLISHED(已建立连接)

(7)B收到确认报文段后也进入(已建立连接)
在这里插入图片描述
8.1 为什么客户端还要有最后一次的确认( 为什么是三次连接不能两次吗?): 防止已失效的连接请求报文又传到了服务器端导致资源浪费

我们假设两个情况 1.客户端的连接请求传给服务器端的过程中不是丢失而是在某个点走了很久直到连接释放了才到B 2.只有两次握手=>

(1) 客户端发送的请求报文段迷路了没有到服务器端,所以迟迟没有收到服务器端的确认报文

(2) 这时客户端会启动超时重传机制,重传请求报文给服务器端,这时候服务器端收到了,并回传确认给客户端,因为是两次握手,所以连接建立,传输完毕,释放连接

(3) 这时候,原先迷路的请求报文到达了服务器端,服务器端会以为这是客户端新发起的连接,在传送确认报文给客户端,两次握手,连接建立,但此时,客户端实际上并没有发起新的连接,所以不会理会服务器端的连接,也不会传输数据,然而服务器端不知道这个情况,所以导致服务器端的资源就这样浪费了

(4) 我们再设想如果是在三次握手的情况下, 服务器端回传这个迷路的确认报文段给客户端,因为客户端并没有新的请求连接,所以不理会服务器端,这时因为是三次握手,所以服务器端再没有收到客户端的确认报文段的情况下不会建立连接,就不会造成上述二次握手造成的资源浪费问题

9.TCP的连接释放(4次挥手)

(1)客户端的应用进程首先向其TCP发出释放连接报文段,停止传送并主动关闭连接,客户端把连接释放报文段的FIN=1,并且序号(seq)=u(其中),u就是传送过的数据的最后一个字节序号+1这时客户端进入FIN-WAIT-1状态
##TCP规定,FIN报文就算不携带数据,也要消耗一个字节##

(2)服务器端收到客户端的连接释放报文时,先立即返回确认释放报文,ACK=1,seq=v,ack=u+1,进入CLOSE-WAIT状态,并且通知服务器端应用进程,此时A->B这一段的连接已经释放

(3)这时TCP连接处于半关闭状态,A没有数据要发了但如果B还是有数据要发送,还是要接收

(4)A收到B的释放确认报文段后,进入FIN-WAIT-2阶段,等待B的连接释放报文段

(5)B数据传输完毕,应用进程通知TCP释放连接,传送释放连接报文段FIN=1,ACK=1,seq=w,ack=u+1,##注意这里的确认好是和,当初传送确认释放连接的确认号相同的##到客户端,进入LAST-ACK状态

(6)客户端收到服务器端的连接释放报文段后,回传确认报文ACK=1,seq=u+1,ack=w+1并进入TIME-WAIT状态

(7)服务器端收到确认后,服务器端进入CLOSE状态

(8)此时TCP连接还没有释放,客户端必须等到时间等待计时器设置的时间2MSL后同时撤销TCB,A才进入到CLOSE状态,自此TCP连接释放

在这里插入图片描述

##为什么TIME-WAIT需要2MSL的时间呢##

如果客户端收到服务器端传送的释放连接报文段后,回传确认释放报文段后就立即关闭,那么当这个回传的确认释放报文段丢失了,服务器端会一直等待,等到启动了超时重传机制,再发送一次FIN+ACK报文段给客户端,在没有TIME-WAIT的情况下,客户端就接收不到再传来的释放连接报文了,这样也不能再传送确认报文给服务器端,服务器端就不能进入CLOSE状态释放TCB结束连接
在TIME-WAIT阶段客户端会撤销相关的TCB,这样在结束连接后,网络中已经没有这一次TCP连接的相关的报文段,这样下一次在建立新的连接时,就不会有已失效的连接请求报文段出现在新的连接中

保活计时器: 现有一个情况,当TCP连接建立了,此时客户端主机故障了,所以服务器就不能在收到客户端的数据,但为了防止客户端明明已经不能传了,服务器端还是傻傻的在等,所以,保活计时器的作用就是,每当收到客户端发来的数据,就重新设置一次保活计时器,但如果没收到,则保活计时器,就开始计算时间,通常为2小时,如果2小时候还是没有收到那么服务器端就会传输一个探测报文段,每隔75秒发送一次,当连续发送10个探测报文段还是没有得到客户端的响应那么,服务端就会判定客户端故障,关闭连接

收录于