文章目录

前言、传输层重点协议
一TCP协议（重要）
- 1.1TCP协议段格式
- 1.2TCP原理
- - 1.2.1确认应答机制（安全机制）
  - 1.2.2超时重传（安全机制）
  - 1.2.3连接管理机制（安全机制）
  - 1.2.4滑动窗口（效率机制）
  - 1.2.5流量控制
  - 1.2.6拥塞控制（安全机制）
  - 1.2.7延时应答(效率机制)
  - 1.2.8捎带应答（效率机制）
- 1.3面向字节流——粘包问题
- 1.4TCP异常情况
- - 1.4.1进程终止
  - 1.4.2机器关机
  - 1.4.3机器断电/网线断开
二、UDP协议
- 2.1UDP协议段格式
- 2.2UDP的特点
三、TCP和UDP对比

提示：以下是本篇文章正文内容，下面案例可供参考

前言、传输层重点协议

传输层是操作内核实现的，我们程序员不需要直接与传输层打交道，但是传输层对我们来说还是意义重大的。

我们进行网络编程需要用到socket,一旦你用了socket代码就会进入传输层（如果出现bug，拥有一些传输层的知识就很有必要）

一TCP协议（重要）

TCP，即Transmission Control Protocol，传输控制协议。人如其名，要对数据的传输进行一个详细的
控制。

1.1TCP协议段格式

源/目的端口号：表示数据是从哪个进程来，到哪个进程去；

32位序号/32位确认号：后面详细讲；

4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是
15 * 4 = 60

6位标志位:
URG：紧急指针是否有效
ACK：确认号是否有效
PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走
RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段
SYN：请求建立连接；我们把携带SYN标识的称为同步报文段
FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段

16位窗口大小：后面再说

16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不
光包含TCP首部，也包含TCP数据部分。

16位紧急指针：标识哪部分数据是紧急数据；

40字节头部选项：暂时忽略；

1.2TCP原理

TCP中有四个核心机制：有连接、全双工、面向字节流、可靠传输，其中可靠传输是引入TCP的关键原因

而确认应答是保证可靠传输的的核心机制

1.2.1确认应答机制（安全机制）

举个例子：现在笔者和女神发消息

如果网络不出现问题，语序是这样的

但是万一网络出现了问题，导致女神的第一二句话发送到我这里的顺序变了（先发后至）

我就很有可能会误解，我会以为她不喜欢吃蛋糕，但是愿意做我女朋友就很尴尬
ps:先发后至的情况对于网络来说很常见，先发的可能绕了个远路，后发的可能超了近道。

为了解决上述可能出现问题，我们可以对发送的消息进行编号

通过编号，我们就可以明确哪句话对应哪个回答。

而放到TCP中我们分别叫这些编号为：“序号”、“确认序号”(确认序号表示当前这个应答报文是针对哪个消息进行确认)

我们的TCP报头就有我们所说的序号和确认序号

序号就表示我们说的是哪条消息，确认序号就表示要对哪条消息进行确认。

序列号是怎么编排的：
TCP中将每个字节的数据都进行了编号，示例图如下：

确认序号是如何应答的：
比如主机A给主机B发送了1-1000的数据，然后B确认就是发送一个1001，表示小于1001的数据已经被B收到，接下来A再发送1001-2000的数据，B确认然后发送一个2001，表示小于2001的数据已经被B收到…

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据；下一次你从哪里开
始发。
ps:可能会有同学问：这1000个数据报中会不会发生后发先至？
回答是——1-1000这是同一个数据报，这一个TCP数据报通过层层封装变成了一个以太网数据帧，进行传输。
如果传了多个数据报，分装成了多个以太网数据帧，多个数据帧之间才会出现后发先至。

1.2.2超时重传（安全机制）

超时重传相当于是对确认应答进行了补充，确认应答是在网络一切正常的时候，通过AKA通知发生方：“我已收到”，但是如果出现了丢包的情况，超时重传机制就要起到效果了。

举例如下：

注意：这里如果触发了超时重发，就会导致接收方收到了重复消息，看上去我们这里的例子重发一遍也没什么影响，但是如果是冲钱的消息呢？一个APP让你冲648你冲了，但是他还没显示，你又冲一个？

针对上述情况，TCP内部就会有一个去重的操作，接收方收到的数据会先放到操作系统内核的“接收缓冲区”中
接收缓冲区可以视为一个内存空间，并且可以视为是一个阻塞队列
如果收到信数据，TCP就会根据序号来检查这个数据是不是在接收缓冲区中已经存在了，如果不存在就放进去，如果存在就直接丢弃了——保证程序调用的socket api拿到的数据一定是不重复的

ps:重传如果也失败了，就会继续很多次尝试，如果达到一定的次数，就会默认为网络出现严重问题放弃重传（自动断开TCP连接）

重传的时间间隔也会逐渐变大，一次传输失败的概率本来就小，然后你重传还失败概率就更小了，如果多次失败，TCP就不指望能重传成功了。

1.2.3连接管理机制（安全机制）

TCP连接管理是网络部分最高频的面试题，一定要重点掌握

（1）如何建立连接——三次握手
三次握手的意思就是客户端和服务器经过三次交互，完成建立连接的过程。
“握手”是一个形象的比喻：客户端给服务器发了一个数据，就是一次握手；服务器返回一个数据，又是一次握手。

具体流程如下：
客户端是主动发起请求的一方，客户端先发送一个SYN同步报文段给服务器

ps:SYN是TCP报头里的

如果SYN这一位为1，就表示当前报文是一个“同步报文段”，主机A和主机B之间要建立连接

客户端把SYN发过去之后，服务器会立即回复一个ACK（表示我收到了你的SYN）
ps:ACK也是TCP报文的一个部分，见上图，如果ACK这位是1，就表示这个报文是“确认报文段”

这个过程有点像谈恋爱确认关系，你客户端给我送了一个礼物SYN表示你的爱慕之情，然后我服务器返回一个ACK表示我收到了你这份心意，然后我如果想和你谈恋爱，我就会也发一个SYN表示我的爱慕之情/doge，然后你再返回一个ACK给我

这样的一个双向奔赴后，我们就完成了建立连接的过程

可能有同学问：你这不是四次交互了嘛？说好的三次握手（交互）呢？
回答——中间的发送ACK和SYN是可以合二为一的，而且也一定会合二为一
（每次传输的数据都需要进行封装和分用，封装两次肯定没一次高效的，所以我们都是合二为一，一次发送）

而让ACK和SYN合在一起也很容易：让它们都是1即可

注：TCP的状态有很多，我们可以先了解一下常见的状态

三次握手的作用?和可靠性有什么关系？
1.三次握手，相当于是“投石问路”，检查一下当前这个网络的情况是否满足可靠传输的基本条件。

举个例子：就相当于是相亲，双方要了解一下对方的基本信息。
换到我们这里，就是检查通信双方的发送能力和接收能力是否正常

2.让双方能够协商一些必要的信息
关于这个协商重要信息我们这里不详细展开，后续知识会有介绍。

我们还是举个例子进行简单介绍：

（2）如何断开连接——四次挥手
三次握手，就让客户端和服务器之间建立好连接，而建立连接之后，操作系统内核中就需要一定的数据结构来保存相关的信息。保存的信息其实是最重要的，也就是前面说的五元组：源IP,源端口，目的IP，目的端口，TCP
（既然是保存了信息，就一定会占用系统资源，比如内存）

但是如果有朝一日服务器和客户端的连接要断开了，那之前保存的连接信息也没有什么意义了，对应的空间也可以释放了。

我们四次挥手流程如下图：

双方各自向对方发送FIN（结束报文段）请求，并且各自给对方一个ACK，确认报文。

三次握手和四次挥手的区别：
三次握手，一定是客户端主动发起的，四次挥手可能是客户端主动发起，也可能是服务器主动发起的

三次握手，中间两次可以合并
四次挥手，中间两次有时候不能合并（有时候可以合并）

有时不能合并的原因在于B发送ACK和B发送FIN的时机是不同的

三次握手中，B给A发的ACK和SYN是同一时机，
因为此处B给A发送的ACK和SYN都是操作系统内核负责进行的

四次挥手中，B给A发的ACK和FIN不一定是同一时机，
因为B给A发送的ACK是内核负责的，B给A发送的FIN是用户代码负责的，B的代码中调用了socket.close()方法，才会触发FIN。又因为执行到用户代码中的close才会触发取决于用户的代码具体怎么写的，所以有时可以，有时不可以

一些补充：

1.2.4滑动窗口（效率机制）

滑动窗口存在的意义就是在保证可靠性的前提下，尽量提高传输效率

我们先来看一下不采取滑动窗口是什么样的

主机A给主机B发送1-1000的数据，要等主机B给一个ACK，主机A才发1001-2000。如果你B的ACK没有发过来，A就会等一段时间，如果还没有发过来，就会重新发送1-1000

可以看出，由于确认应答机制的存在，导致了当前每次执行一次发送操作，都需要等待上一个ACK的到达，大量的时间都花在等ACK上了。

滑动窗口本质就是“批量地发送数据，一次发一波数据，然后一起等一波ACK”，如下图：

一次等待时间，可以等待多份ACK，就可以把多份等待ACK的时间压缩成1份了。
ps:可能会有同学问：“能不能不等ACK，那这样速度不是更快？”
回答是：“TCP是得保证可靠传输的，可靠传输的灵魂就是确认应答，如果没有这个ACK，可靠传输形同虚设。所以，等ACK是必须得等的。”

如果一次批量发送数据为N，统一等待一波，此时的N称为窗口大小

滑动的意思是，并不用把N组数据的ACK都等到了，才能继续往下发送，而是收到了一个ACK，就继续往下发送一组

举个例子：
当前是在等待1001,2001,3001,4001四组ACK，我们并不需要4001到了，才继续往下发送。

只要1001到了，就可以往下多发一组（4001-5000），此时等待的ACK就是2001,3001,4001,5001。

如果2001到了，继续往下发一组（5001-6001），此时等待的ACK就是3001,4001,5001,6001

以此类推…

当2001这个ACK到达后，就认为1001-2000这个数据已经收到了，然后就可以立即发送下一组了。这样要等待的ACK范围就发生变化了，我们认为上图的白色窗口（要等待的ACK）好像滑动了一样。

ps：当前这个窗口更大，传输速度就更快。因为窗口大了，同一份时间内等待的ACK就更多，总的等待ACK时间就少了

到这里可能会有同学有疑问：“会不会出现2001没到，3001先到的情况？”
这也是我们接下来要讨论的问题：“如果我们的数据是批量发送，在滑动窗口的背景下，如果丢包，怎么重传呢？”

丢包分成两种情况：
1.ACK丢了

上图中，我们是举例了一种极端的情况，6组数据丢了3组ACK（1001,3001,4001）

我们发送4001之前，1001丢了，但是我们收到了2001。仔细想想，2001表示的意思是2001之前的数据都已经确认收到了，那么1001能否收到已无足轻重了。ACK确认序号的特定含义，就保证了后一条ACK能覆盖前一条ACK。

后面3001、4001丢了，都没有任何关系，只要我们5001ACK到了就行（5001就涵盖了3001和4001表达的信息）

举个不太恰当了例子：
你谈个对象，那你的大致步骤如下：
1.拉小手
2.抱抱
3.么么哒
4…（以下内容需要付费观看）
你如果闯关都到第四关了，就说明你前面几关都闯过了/doge

2.数据丢了

由于1001-2000这个数据丢了，所以B就会反复向A索要1001这个数据。即使A已经给B往后发了，这个时候B仍然是在索要1001

当索要若干次后，A就知道1-1000丢了，所以会触发重传

而当1001-2000重传之后，由于之前A已经发过了6001-7000，所以B在接收到1001之后会立即返回一个7001

ps：关于B的接收缓冲区
在A重传1001-2000之前

A重传1001-2000之后

1.2.5流量控制

流量控制是滑动窗口的延伸，目的是保证可靠性

在滑动窗口中，窗口越大，传输效率就越高
不光要考虑发送方，还得考虑接收方

发送方发的贼快，接收方根本处理不过来，接收方就会把新收的包丢了，那发送方又得重传…

流量控制的关键，就是得能够衡量接收方处理的速度，此处就直接使用接收方缓冲区的剩余空间大小，来衡量当前的处理能力

接收方如何告知发送方剩余空间有多大呢？
是通过ACK报文来告知的

虽然这里的窗口大小是16位，实际上窗口大小不止16位，还可以更大

流量控制流程图如下：

1.2.6拥塞控制（安全机制）

拥塞控制衡量的是，发送方到接收方，这整个链路之间，拥堵情况（处理能力）

不管A和B之间有多少设备，有多少个，我们把中间部分设为一个整体，A开始以一个比较小的窗口来发送数据，如果数据很流畅的就到底了，逐渐加大窗口大小，如果加大到一定程度，出现丢包了（意味着通信链路出现拥堵了），这个时候再减小窗口。

通过反复的增大/减小，我们就可以逐渐摸索到一个合适的范围，拥塞窗口就在这个范围中不断变化，达到“动态平衡”。

有点类似举重运动员的负重训练：先给轻一点的杠铃，然后逐渐加大，如果过重了就减轻一些——太轻了起不到锻炼效果，太重了容易受伤。

具体这个拥塞窗口是如何变化的呢？请看下图：

1.2.7延时应答(效率机制)

就相当于流量控制的延伸，流量控制是踩了一下刹车，使发送方发的不要太快，延时应答就是在这个基础上，能够尽量的让窗口更大一些。

举个例子：

1.2.8捎带应答（效率机制）

捎带应答又是延时应答的延伸

我们客户端和服务器之间的通信，有以下几种模型：
1.一问一答：客户端发送一个请求，服务器返回一个对应的响应
2.多问一答：比如上传文件
3.一文多答：比如下载文件
4.多问多答：比如直播

其中最典型的就是模型1，我们以这个为介绍

但是，我们的ACK由于延时应答的存在，不一定会立即返回，它会往后延时一会。
而延时一会就很有可能会与我们的应用程序返回的时机重合，那么触发时间相同了，就可以合并了。

1.3面向字节流——粘包问题

TCP粘包是指粘的是应用层数据报，在TCP接收缓冲区中，若干个应用层数据报混合在一起了，分不出来谁是谁了
ps:不仅仅TCP存在粘包，其他面向字节流的机制也存在，比如读文件。

我们这里的解决方案：关键就是在应有层协议这里，加入包之间的边界（粘包问题，说是TCP问题，实际是应用层问题），比如这里约定是以“;”结尾

如果你是基于一些库/框架来完成网络通信，一般来说粘包问题已经被库/框架处理了，如果你是需要自己实现一些库/框架，直接使用了TCP，就需要考虑到粘包了。

1.4TCP异常情况

1.4.1进程终止

在进程毫无防备的情况下，偷袭！看来是有bear来

这个时候该进程的TCP连接是咋样的？

TCP连接，是通过socket来建立的，socket本质上是进程打开的一个文件，文件其实就存在于进程的PCB里面有个文件描述表
每次打开一个文件（包括socket）,都在文件描述符表里，增加1项。
每次关闭一个文件，就在文件描述表里，删除一项

如果直接杀死进程，PCB也就没了，里面的文件描述表也就没了，此处的文件就相当于“自动关闭了”
这个过程其实和手动调用socket.close()一样，都会触发4次挥手

进程没有大意，它有闪

1.4.2机器关机

按照操作系统约定的正常流程关机

正常流程的关机，会让操作系统杀死所有进程，然后再关机

这样就和进程终止一样了，又偷袭失败了

1.4.3机器断电/网线断开

按传统功夫讲是讲化劲的，四两拨千斤
直接拔电源，偷袭！他没有任何反应时间，更不会有任何的处理措施

二、UDP协议

2.1UDP协议段格式

上图是很多教材的画法（之所以这样话是为了印刷时的排版），实际格式如下：

第一、二个部分：源端口和目的端口

（1字节=8比特，2字节也就是16位）

代码中写的端口号，就会被打包到这样的UDP数据报中（在报头体系）
以UDP客户端为例：

可能会有人问：“能不能把UDP这里的端口改成4个字节或者其他的？”

回答——这东西是操作系统内核实现的，你windows源码都没有怎么改，另外2个字节也足够用了没必要改。

第三个部分：UDP的长度

报文长度是2个字节，范围是0~ 65535，对于十几年前0~65535这个范围太够用了，但是现在这个年代就很小了。

这也是UDP使用中一个非常致命的缺陷——无法表示一个比较大的数据报。

如果你想要表示一个比较大的数据报，解决办法如下：

1 .可以在应用层，针对大的数据报，进行分包（拆成多个部分），然后再通过多个UDP数据报分别发送。但是分别发送也有缺陷——不能保证顺序，那只能接收方再把收到的几个包重新拼接（下策，拆包组包太麻烦了）

2 .改成TCP，TCP没有长度限制

最后一个部分：校验和

校验和是用来验证网络传输的数据是否是正确的。

网络上传递的数据本质上是光信号和电信号，如果出现外界干扰，比如磁场什么的…可能就会导致数据出错。

比如：现在发一组连续的高频信号，但是遇到强磁场，可能会导致其中某些高频信号变成低频
校验和就会帮助我们发现其中的错误。

举个例子：
我出门买烧烤，我媳妇要我买羊肉串、牛肉串、烤五花肉、烤韭菜，最后再多嘱咐一句“一共四种”，这一共四种就是校验和。

但是校验和一定能保证数据正确吗？不一定，同样是上面的例子，我媳妇要我买4种烧烤，我买了羊肉串、牛肉串、烤五花肉、猪脑花。这也是四种，但是就和前面要求的不一样了。

当然了，计算校验和的时候，也不一定单纯的使用“个数”，还可以使用数据内容参与运算，如果是基于数据内容得到的校验和就更容易识别出错的内容

2.2UDP的特点

UDP传输的过程类似于寄信。

无连接
知道对端的IP和端口号就直接进行传输，不需要建立连接；

不可靠
没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方，UDP协议层也不会
给应用层返回任何错误信息；

面向数据报
应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并；

缓冲区
UDP只有接收缓冲区，没有发送缓冲区：

UDP的socket既能读，也能写，这个概念叫做全双工

大小受限
UDP协议首部中有一个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K（包含UDP首
部）。

三、TCP和UDP对比

1.什么时候使用TCP？
对可靠性要求高（日常开发中的大多数情况都是基于TCP）
2.什么时候使用UDP？
对可靠性要求不高，对于效率要求更高（比如机房内部的主机之间通信，分布式系统中）

比如保证可靠性最核心的——确认应答+超时重传，实现的同时要确保其中引入了序号，再进一步保证可靠性也就是连接管理，你也可以搞一个三次握手、四次挥手，再进一步，如果效率比较低，就滑动窗口，而为了限制滑动窗口，就可以有流量控制…

TCP的这些机制都可以照抄在UDP里面，只不过TCP是内核实现好的，如果是基于UDP实现可靠传输，那就是在应用层实现，代码代价更大一些。

Java ee 传输层重点协议TCP/UDP相关推荐

网络原理 | 传输层重点协议之TCP协议(TCP连接的三次握手与四次挥手、TCP的安全机制与效率机制)
目录 TCP协议安全机制确认应答机制超时重传机制连接管理机制三次握手四次挥手流量控制机制编辑拥塞控制机制效率机制滑动窗口机制延迟应答机制捎带应答机制 TCP协议 · 传输层的 ...
网络编程之传输层的协议TCP与UDP
传输层协议: TCP和UDP的区别: TCP:面向连接(经历三次握手).传输可靠(保证数据正确性,保证数据顺序).用于传输大量数据(流模式).速度慢,建立连接需要开销较多(时间,系统资源). 服务端和 ...
tcp udp区别优缺点_CCNA必懂篇，传输层协议TCP/UDP的区别和作用
我们说会话层建立连接之后,就要建立传输层连接,那么为什么要建立这个传输层连接呢,我们先看一下传输层的作用是什么? 传输层的主要作用是处理我们的数据在发送的时候产生的数据包错误,数据包次序不对,数据丢失 ...
8月11日网工学习 APR协议传输层协议 TCP UDP 数据封装转发全过程
目录 APR协议传输层协议 TCP UDP 数据封装转发全过程 APR协议作用:将IP地址解析为MAC地址 ARP的主要内容在ARP高速缓存表中查找目的IP地址对应的MAC地址广播发送ARP请 ...
计算机网络-传输层（传输层概述，TCP，UDP协议概述）
文章目录 1. 传输层概述 2. TCP,UDP协议概述 3. 传输层的寻址与端口 1. 传输层概述传输层是只有主机才有的层次. 传输层功能: 传输层提供进程和进程之间的逻辑通信. 网络层提供主机到 ...
传输层端口、TCP和UDP的概念
端口端口号用来识别同一台计算机中进行通信的不同应用程序. 端口用一个16位端口号进行标志.端口号只具有本地意义,即端口号只是为了标志本计算机应用层中的各进程. 简单来说客户机上运行着多个应用进程, ...
计算机网络之传输层：2、UDP协议
传输层:2.UDP协议 UDP特点: UDP首部格式: UDP校验过程: UDP特点: UDP首部格式: UDP校验过程: 伪首部不向上交付也不向下交付,只在UDP数据报校验的时候出现 UDP校验过程 ...
OSI七层模型详解物理层、数据链路层、网络层、传输层.....应用层协议
OSI七层模型详解(物理层.数据链路层.网络层.传输层.....应用层协议与硬件) OSI 七层模型通过七个层次化的结构模型使不同的系统不同的网络之间实现可靠的通讯,因此其最主要的功能就是帮助不同类型 ...
计算机网络4小时速成：网络安全，被动攻击，主动攻击，对称加密，公钥秘钥，数字签名，鉴别，网络层安全协议IPsec，传输层安全协议SSL，防火墙，入侵检测系统
计算机网络4小时速成:网络安全,被动攻击,主动攻击,对称加密,公钥秘钥,数字签名,鉴别,网络层安全协议IPsec,传输层安全协议SSL,防火墙,入侵检测系统 2022找工作是学历.能力和运气的超强结合 ...

Java ee 传输层重点协议TCP/UDP