【网络原理】震惊~~ 这是我见过最详细的TCP和UDP讲解

前言.

传输层: 传输层是TCP/IP协议五层模型中的第四层。他的主要工作是负责两台主机之间的数据传输.TCP和UDP都是传输层中的重要协议.
再谈端口号(Port): 标识了⼀个主机上进行通信的不同的应用程序
- 0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的.
- 1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的.
认识知名端口号(Well-Know Port Number)
- ssh服务器, 使用22端口
- ftp服务器, 使用21端口
- telnet服务器, 使用23端口
- http服务器, 使用80端口
- https服务器, 使用443端口.
一个进程可以绑定多个端口号，但是多个进程绑定同一个端口号通常是不被允许的，因为端口号是网络服务的一个唯一标识，多个进程绑定相同的端口会导致冲突和混淆。

UDP协议

UDP协议报文的基本格式:
16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度,也就是说一个UDP所能传输数据的最大长度为64K (包含UDP首部);一旦数据报的长度大于64K,此时就可能导致数据阶段(数据的后面部分被截断了)
如果校验和出错, 就会直接丢弃;

UDP校验和的计算方式时，可以分为以下几个步骤：

数据包划分：首先将整个UDP数据报文划分为多个16位（2字节）的片段。如果最后一个片段不足16位，需要用0来填充至16位。
求和运算：对上述所有划分出来的16位片段执行二进制反码求和运算。这个过程中，可能会涉及无符号定点数的加法。
取反操作：将求和的结果取反，得到的结果即为校验和。这个步骤确保了校验和能够反映出数据报文中的任何修改。
校验和放置：计算出的校验和会被放置在UDP头部的特定字段中。发送方完成这一步骤后，数据报就可以被传送到网络上。

需要注意的是，接收方在收到数据报之后，也会执行一次同样的校验和计算过程。如果计算出的校验和与数据包中的校验和字段不匹配，则说明数据在传输过程中可能发生了错误。

UDP协议的特点

无连接:知道对端的IP和端口号就直接进行传输, 不需要建立连接,通信双方不需要保存对方的信息.
不可靠传输:没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息.换句话说就是我只管发,到没到我不管.
面向数据报:应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
用UDP传输100个字节的数据:–如果发送端调用⼀次sendto, 发送100个字节, 那么接收端也必须调用对应的⼀次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;
全双工:UDP是一种全双工通信协议。 UDP协议首部中有一个16位的大长度. 也就是说一个UDP能传输的报文长度是64K(包含UDP首部)。如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装。

基于UDP的应用层协议

NFS: 网络问件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议

TCP协议

TCP全称为 “传输控制协议(Transmission Control Protocol”). 顾名思义, 要对数据的传输进行一个详细的控制;
TCP协议报文的基本格式:
在这里插入图片描述

16位源端口/目的端口:表示数据是从哪个进程来,要到哪个进程去.
32位序号位:序号是可靠传输的关键因素。TCP将要传输的每个字节都进行了编号，序号是本报文段发送的数据组的第一个字节的编号，序号可以保证传输信息的有效性。比如：一个报文段的序号为300，此报文段数据部分共有100字节，则下一个报文段的序号为401。
32位确认序号:每一个ACK对应这一个确认号，意思是告诉发送者, 我已经收到了哪些数据; 下⼀次你从哪里开始, 发确认号只有当ACK标志为1时才有效。比如建立连接时，SYN报文的ACK标志位为0。
6位保留位:后续一旦需要扩展功能,使用保留位就可以做到,可以避免TCP扩展引起的不兼容问题.
6位标志位:
- URG: 紧急指针是否有效
- ACK: 确认号是否有效
- PSH: 提示接收端应用程序力刻从TCP缓冲区把数据读走
- RST: 对方要求重新建立连接; 我们把携带RST标识的称为复位报文段
- SYN: 请求建立连接; 我们把携带SYN标识的称为同步报文段
- FIN: 通知对方, 本端要关闭了, 我们称携带FIN标识的为结束报文段
16位窗口大小:就可以根据这个字段来给发送方反馈返送速度. 这个字段在其他报文中没有意义,只有在ACK应答报文中才有意义.
16位校验和:发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分.
16位的紧急指针：按序到达是TCP协议保证可靠性的一种机制，但是也存在一些报文想优先被处理，这时就可以设置紧急指针，指向该报文即可.

CRC校验算法.

CRC算法也叫循环冗余检验.

发送方在发送之前,会先计算一遍CRC,把计算好的CRC的值放到数据报中(假设这个值为value1).接下来通过网络把这个数据包传输给接收端,接收端收到这个数据之后,也会按照同样的算法,再计算一遍CRC的值(假设此处得到的结构为value2),比较自己计算的value2和数据报中的value1是否一致====>如果一致说明数据🆗,如果不一致就说明数据发生了bit翻转.
如果只有一个bit位发生翻转,此时100%能够发现问题,但是如果是有两个/多个bit位发生翻转,就有可能和之前计算的校验和一样(value1)!!==>这种情况发生的概率比较低可以忽略不计.如果要追求更高精度的校验此时就需要使用其他更严格的检验算法了.

TCP相关机制的介绍.

1.确认应答(确保可靠传输最核心的机制)

在网络传输的过程中,发送方给接收方发送数据,如果接收方给予响应,则称为应答(应答报文段ack)
但是由于网络传输的复杂性,就可能出现后发先至的情况.(此时就可能会出现一系列问题)
举个简单的例子:
你给你的女神发消息,先发了一个"晚上一起出来吃火锅",接着又发了个"做我女朋友好不好" . 接收方回应了一个"好"和"滚",但由于网络传输的原因出现了后发先至的情况,此时就会曲解本来要表达的意思了.
为了解决上述问题,就引入了序号和确认序号–>换句话说序号就是给发送方要发送的内容进行编号,确认序号就是对接收方应答的响应也做出对应的编号,即一个序号对应一个确认序号.
报头中的序号只能存一个.但由于序号是连续的,因此我们在报头中存储的序号就是第一个字节的序号.
应答报文中的确认序号,是按照发送过去的最后一个字节的序号+1来进行设定的

2.超时重传(是对确认应答的补充)

在数据传输的过程中,可能会出现"丢包"的情况,假设主机A给主机B发送数据,但主机A收不到主机B返回的任何信息,此时就可能是"丢包"了
- 一种情况是:发送的过程中丢了,即接收方没有收到包.==>数据丢了. 这种情况重传数据包没任何问题.
- 另一种情况就是在返回的过程中丢包了,即ack丢了. 这种情况数据接收方已经收到了,再传输一次,就意味着接收方收到了两份数据,此时就会产生问题
  - 解决方法 : TCP Socket在内核中存在接收缓冲区,此时发送方发来的数据会先放到内存缓冲区之中,然后应用程序调用Scanner/Read来读取数据.=>当数据到达接受缓冲区的时候,接收方会首先判定一下看当前缓冲区是否存在这个数据了(或者这个数据在内存缓冲区曾经存在过)=>如果已经存在或者存在过,就把重复发来的数据丢掉了~~就能确保应用程序在读的过程中不会出现重复数据了
超时重传并不是无限次的重传.也是有一定的策略的:
- 重传的次数是有上限的,重传到一定次数,还没有ack,就尝试重置连接,如果重置也失败就放弃连接
- 超时重传的时间阈值也不是固定不变的,会随着重传次数的增加而增大.(重传的频率会降低)

3.连接管理

建立连接(三次握手)

内核是如何建立连接的?(三次握手,本质上就是通信双方各自给对方发送一个syn,各自回应对方一个ack)
1. 第一次交互一定是客户端发起的===>客户端会给服务器发送一个syn数据报(告诉她我想和她建立连接).
  - syn(同步报文段)是一个特殊的TCP数据报—特点:①没有载荷,不会携带应用层数据…②.六个标志位的第五位为1
  - 虽然syn数据报不带有载荷,但是封装分用的过程仍然存在.所以syn数据报的报头仍然会具有’‘TCP报头’‘,’‘IP报头’‘,’'以太网数据帧"—>syn中存有客户端自己的端口号和IP地址(建立连接要告诉她我是谁,我在哪)
  - syn这样的数据报,不携带载荷,没有应用层数据,也就不代表任何应用层的业务逻辑,syn起到的作用就仅仅是打招呼.
    此时就会出现两种情况:
    ①服务器同意和你建立连接.
    ②服务器拒绝和你连接. (一般这种情况比较少见,除非服务器出现负载极高的情况,服务器完全无法响应).
2. 服务器在收到客户端发来的syn之后会做两件事情:
  - 返回ack(确认应答)---->(告诉客户端我收到你的请求了).
  - 再返回一个syn—>(告诉客户端我也想和你建立连接).
3. 客户端再收到服务器发来的同意请求之后,再给服务器发送一个ack应答报文
4. 注:
  - 这里客户端的信息告诉服务器确实在第一次握手的时候就完成了.但是服务器是否确定要存储这个信息还需要观望.等到所有的握手环节都结束,服务器才会最终保存客户端的相关信息
  - 还没有最终确定要建立这个连接,确定出后需要进行通信,还要所有流程都走完.

为啥要进行握手?握手的意义是什么?

三次握手,可以先针对通信路径,进行投石问路,初步确认一下通信道路是否畅通.
三次握手,也是在验证通信双发,发送能力和接收能力是否正常.
- 为啥必须是三次握手,四次可以吗?(可以但没必要)两次可以吗?
  - 两次握手不能够验证服务器的发送能力,和对端的接收能力是否正常.
三次握手的过程中也会协商一些必要的参数.
- TCP中也是有很多参数是需要协商的.这些东西往往是在选项的部分体现出来的(最少0字节,最多40字节)
- 其中有一个重要的信息,TCP通信的序号起始值.(TCP通信过程中序号不是从0开始的,而是选择一个比较大的数字,作为开头进行通信).即使是同一台设备,每次连接的序号都不同.

断开连接(四次挥手)

连接本质上是就是让通信双方保存各自的信息(每个客户端/服务器都要保存多个对端信息),就需要用到一定的数据结构来存储对端信息.
断开连接的本质目的就是为了把对端信息从数据结构中删除/释放掉.
如何一步步断开连接?(本质上也是通信双方给各自对方发送一个fin,各自回应对方一个ack)
- 1. 调用socket.close()/进程直接结束会触发fin(fin也是内核负责完成). 客户端/服务器给对端发送fin结束报文段.
- 1. 服务器在收到客户端发来的syn之后会做两件事情:
  - 返回ack.告诉客户端/服务器我知道你要结束了(断开连接了)
  - 客户端/服务器给对方也发送一个fin结束报文段(我也同意要和你断开连接了).
- 1. 客户端/服务器也给对方返回一个ack.(此时彻底断开连接了).
四次挥手能否像三次握手一样,把中间两部合二为一呢?为什么?
有时候能有时候不能.有的时候能合并,有的时候不能合并.
在建立连接的时候,服务器收到syn之后,发送(ack和syn)的时机是一致的,都是内核在收到syn之后立即触发的.这两个数据报的触发和应用层代码无关.
在断开连接的时候,服务器在收到fin之后,发送ack是内核立即发送的,但是服务器的fin不是由内核来完成发送的,而是要调用应用层代码.socket.close()来完成fin的发送. 此时就可能出现问题–>如果实际通信过程中,ack和fin中间的时间间隔比较长.此时就无法合并了,需要保证逻辑的正确性.
如果时间间隔很小.是有可能会合并的.依赖于TCP的延时应答和捎带应答机制.

LISTEN状态:表示服务器这边已经创建好ServerSocket对象了,并且已经绑定好了端口号.
Established 以确立的.客户端和服务器连接已经建立了(三次握手握完了)
CLOSE_WAIT 表示接下来的代码中需要调用close来主动发起fin.(收到fin后会进入这个状态).
TIME_WAIT 表示本端在发送FIN之后也收到了对端发起的FIN(谁主动断开连接,谁进入这个状态)

4.滑动窗口

滑动窗口就是在保证可靠传输的前提下,提高效率(这里的提高效率其实是降低损失,而不是增加速度).虽然通过这个机制提高了效率,但是TCP传输的效率仍然低于UDP这种不可靠传输的.本质上就是把多次请求等待的时间,使用同一份时间来等了,减少了总的等待时间
如果出现丢包问题,滑动窗口会咋样??

ACK应答数据报丢了.这种情况不需要进行任何处理,对于TCP可靠传输没有任何影响,也不需要进行重传.可以通过后续的ack来确保确保前面的以及传输到了

在这里插入图片描述
2. 数据包直接丢了

当某⼀段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是
1001” 一样; 反复索要就是在给1001到达留有等待时间,连续多次索要,数据包还没有到达,此时就可以认为是数据包丢了.相当于超时时间判定.
如果发送端主机连续三次收到了同样⼀个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新
发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就
已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
上述重传的过程中,整体的效率是比较高的.这里做到的重传是"针对性"重传,哪个丢了重传哪个,已经收到的数据是不必要重复发送的,整体的效率没有额外的损失,此时就把这种重传称为"快速重传".
确认应答/超时重传/滑动窗口/快速重传之间的内在联系?
他们之间是并不冲突的,而且是同时存在的
1. 滑动窗口中当然也有确认应答,只不过把等待的策略进行了调整,转成批量的了.批量的前提是你短时间发了很多数据.如果你发的数据很少,此时滑动窗口也就退化成了确认应答.
2. 如果传输的过程是按照滑动窗口(短时间内传送大量数据)就按照快速重传来保证可靠性,此时判定丢包的标准就是连续看到多个ACK索要同一个数据.
3. 如果传输的过程不是按照滑动窗口(没有传输很多数据)就按照超时重传来保证可靠性,此时判定丢包的标准就是达到超时时间,还没有ACK到达.
5.流量控制(对滑动窗口的补充,保证可靠性,站在接收方的角度来制约发送方的速率)
- 接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送, 就会造成丢包, 继而引起丢包重传等等⼀系列连锁反应.因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)
- 十六位窗口大小:就可以根据这个字段来给发送方反馈返送速度. 这个字段在其他报文中没有意义,只有在ACK应答报文中才有意义. 通过这个大小来发聩给接收方接下来要发送的窗口设置成多少合适.—>接收方就会按照自己接收缓冲区剩余空间的大小,作为ack窗口大小的数值.下一步发送方就会根据这个数值来调整自己的窗口大小.
- TCP报头中还包含一个参数叫做窗口扩展因子,并不是64位…实际上真实要设置的窗口的大小 = 16位窗口大小*2^扩展窗口因子.
- 发送方何时重新发送呢?
  发送方会周期性的触发窗口探测包,这个包并不携带载荷. 对业务不产生任何影响,只是为了触发ACK .一旦查询出来的结果为非0,此时缓冲区就不满了,此时就又能继续发送数据了.

6.拥塞控制(对滑动窗口可靠性的补充,与流量控制一样,都是要限制发送方发送数据的速率)

总的原则就是,流量控制和拥塞控制,谁产生的窗口大小更小,谁就说了算.
动态窗口的大小是一直在变的(网络的复杂不稳定),动态平衡
拥塞控制具体怎么把窗口大小试出来的呢?
1. 慢启动.刚开始传输的数据速率是比较小的,采用的窗口大小也就比较小.(拥塞窗口) -->此时网络的拥堵情况未知,如果一上来就传输很多数据,可能就让本不富裕的网络带宽,雪上加霜了
2. 如果上述传输的数据,没有出现丢包,说明网络是畅通的,就要增大窗口大小.此时的增大方式是按照指数的方式来增长的(*2);
3. 不会一直持续保持指数, 有可能因为增长太快,一下就导致网络拥堵. 因此就引入了一个阈值,当拥塞窗口达到阈值之后,增长方式就由指数增长变为了线性增长.
4. 线性增长也是一直在增长,积累一段时间之后,仍然可能导致传输速率过大,从而引起丢包.一旦出现丢包,就要把拥塞窗口重置成较小的值.回到最初的慢启动的过程(又要重新开始指数增长)==>并且这里也会根据刚才丢包时的窗口大小,重新设置阈值

7.延迟应答(也是基于滑动窗口,再提高一点传输效率)

结合滑动窗口以及流量控制,能够通过延迟应答ACK的方式.把反馈的窗口大小,搞大一点.—>核心就是在条件允许的范围内,尽可能让窗口的大小尽量的大.
当数据到达接收方之后,不会立即返回ack,而是等待一会,让接收方能够继续读取一些数据. 此时再返回的窗口大小就会变得更大了
通过滑动窗口来传输数据----->如果ack丢了,没啥影响.延时应答具体怎么延时,也不是单纯的按照时间,而是可以按照"ack丢了"来处理. 正常每个数据都有ack,此时就可以每隔几个数据(也有一个时间下限)返回一个ack. 也能减少ack传输的数量,也能起到减少开销的作用

8.捎带应答(基于延时应答引入的机制,能够提高传输的效率)

捎带应答走的是一条,尽可能把数据包进行合并,从而达到提高效率的效果.
在捎带应答的加持下,后续每次传输请求响应,都可能触发捎带应答,都可能把接下来要传输的业务逻辑和上次的ack合二为一了
如果你下一个数据来的很快,在延时应答的延时时间之前到达,就可以触发捎带应答…如果你下一个数据来的慢,就无法触发这个机制了.
因为延时应答+捎带应答 ,使后续的四次挥手,可能合并成三次

9.面向字节流中的粘包问题

粘包问题是TCP引起的,但是TCP本身不会解决,需要程序员写应用层代码的时候自行去解决.
此处的包是TCP载荷中的应用层数据包----->TCP传输的数据达到接收方之后,接收方要根据socket api来读取read出应用层数据包.—>由于整个read的过程非常灵活,可能会使代码中无法区分当前的数据从哪到哪是一个完整的应用数据包
解决粘包问题的关键就是"明确包之间的边界"
1. 通过特殊符号,作为分隔符 .见到分隔符就意味着一个包结束了(使用任意字符作为分隔符否可以,需要确保当前这个分隔符不会在数据中出现)
2. 指定出包的长度.比如在包的开始位置,加上一个空间来表示包的长度

对应的UDP没有这个问题.UDP传输的基本单位是UDP数据报.在UDP这一层就已经分开了,只要约定好一个UDP数据报都只承载一个应用层数据包,此时就不需要额外的手段来进行区分了.---->UDP的接收缓冲区不是像队列这样的结构,而是类似于链表这样的结构

10.异常情况

其中有一方出现了进程崩溃
- 进程无论是正常结束,还是异常崩溃,都会触发文件资源回收,关闭文件这样的效果.(系统自动完成的),此时就会触发四次挥手.
- TCP连接的生命周期,可以比进程更长一些.虽然进程已经退出了,但是TCP的连接仍然还在,仍然可以继续进行四次挥手
- 虽然说是异常崩溃,实际上和正常的四次挥手没有任何区别.即使进程不在了,但可以通过系统中仍然存在的连接信息,完成四次挥手的过程
其中有一方出现了关机(正常关机)
- 当有一个主机触发关机操作,就会先强行终止所有进程(类似与上述的强杀进程) ,也会触发四次挥手.
- 但是四次挥手不一定不一定能挥完,因为系统马上就关闭了
  - 如果挥的快,能够顺利挥完,此时本端和对端都能正确的删除保存的连接信息.
  - 如果删的不快,至少也能把第一个fin发给对端,至少告诉对端(我这边要结束了),对端收到fin之后,对端也就要进入释放连接的流程了,返回ack,并且也发fin,这里发fin就不会有ack响应了,此时没有收到ack,就会触发超时重传机制,当重传几次几次之后,仍然没有收到ack,此时就会单方面释放资源了
其中有一方出现了断电(非正常关机)
- 断电的是接收方.发送方就会出现收不到ack的情况了,就会触发重传机制,但是重传几次仍然没有收到ack,此时TCP就会尝试"复位"连接,相当于清除原来TCP中的各种临时数据,重新开始…此时就设计到了TCP协议中的一个报文段—“复位报文段”.----->RST之后,仍然没有ack,此时就会单方面放弃连接
- 断电的是发送方.此时接收方本来就是在阻塞状态,等待发送方,发送数据—<此时就接收方就需要,判断出发送方是挂了,还是好着呢暂时没发====>TCP的做法就是给发送方发送一个"心跳包"(周期性的,如果没有心跳则认为发送方挂了),此时也会尝试复位单方面删除对端数据.
网线断开.
本质上就是情况三的两种情况结合