终于总结了传输层的TCP协议~~~

一.理解TCP(重点!!!)

即传输控制协议,就是要对数据的传输进行一个详细的控制

1.TCP的协议格式

二.TCP的安全机制

1.连接管理机制(重要!!!)

1.三次握手的流程

• 主机A发送syn到主机B,要求建立A到B的连接,主机状态为syn_sent
• 主机B回复ack+syn,要求建立主机B到A的连接,主机B状态为syn_rcvd
• 主机A回复第2步syn的ack,主机A状态为established,主机B状态设置为estab

注意点:
(1)syn为什么有两个?
双方会保存连接状态(有方向的)
(2)第2步,为什么是ack+syn?
本质是发一个ack应答,一个syn请求,方向相同的两个数据报,可以合并
(3)第3步,ack确认应答哪个?
应答第2步的syn

2.四次挥手的流程

• 主机A发送fin到主机B,请求关闭a到b的连接
• 主机B回复ack,主机B状态置为close_wait
• 主机B发送fin到主机A,请求关闭B到A的连接
• 主机A回复主机ack(第3步的ack)状态置为time_wait,主机B接收到第四步的数据报,状态置为closed

主机A经过2MSL(超时等待时间)之后,状态置为closed
注意点:
(1)第2,3步,为啥不能合并?
第2步是TCP协议在系统内核实时,自动响应的ack,第3步是应用程序手动调用close来关闭连接,程序在关闭连接前,可能需要执行释放资源等前置操作,所以不能合并(TCP协议实现时,没有这样设计)
(2)第3步,主机A为啥不能直接设置为closed状态
第4个数据报可能丢包:主机B到达超时时间后,重发第3个数据报,会要求主机A再次回复ack
(3)服务器出现大量的close_wait状态,是啥原因?怎么解决?
服务端没有正确的关闭连接(程序没有调用close,或没有正确调用)

2. 确认应答机制

1.原理

• 保证安全:我发送的信息,对方必须确认并回复
• 保证多条数据确认消息的安全(序号+确认序号)

2.实现

• 实现发送时:携带数据序号
• 确认回复时:携带确认序号

3.超时重传机制

1.原理

如果主机A在一个特定的时间间隔内没有收到主机B发来的确认应答,就会进行重发

2.没有收到确认应答的情况

• 数据报丢了
• ack确认应答数据报丢了

3.超时时间如何确定

根据当前网络环境的情况(决定发送数据的速度),得到单次报文发送的最大生存时间(MSL),超时时间即为2MSL
注意:TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间

4.一直收不到ack,超时时间会如何设置

• 多数操作系统中,超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍
• 如果重发一次之后,仍然得不到应答,等待2*500ms后在进行重传
• 如果仍然得不到应答,等待4*500ms进行重传,以此类推,以质指数形式递增
• 累积到一定的重传次数,TCP认为网络或者对端主机出现异常,强行关闭连接

4.流量控制机制

• 接收端接收能力有限,告诉发送端接收能力
• 流量控制窗口:基于tcp报文中窗口大小字段来设置(影响到发送端滑动窗口的大小)

5.拥塞控制机制

1.概述:

发送端网络状态不明的情况,贸然发送大量数据报,会造成网络拥堵,先发送数据探路,设置拥塞窗口大小)

2.拥塞窗口大小如何确定?

• 慢启动：一开始只发送少量数据，探测一下网络拥塞程度，然后逐渐增大传输的数据，拥塞窗口也就会小到大指数增长；
• 拥塞避免：当拥塞窗口达到慢启动的阈值的时候，使用拥塞算法让拥塞窗口缓慢增加，不再指数增加，而是加法增大（每经过一个往返就把窗口大小加1），这样拥塞窗口就会按照线性规律缓慢增加；
• 快重传与快恢复：快速恢复丢失的数据包；
• TCP开始启动的时候，慢启动的阈值等于窗口的最大值；超时重发的时候，慢启动的阈值会变为拥塞窗口最大值的一半，同时拥塞窗口置回1；

三.TCP的效率机制

1.延迟应答机制

接收端收到数据,马上响应ack,流量控制窗口大小(接收端接收缓冲区空余空间)就会比较小
影响滑动窗口大小(窗口越大,效率越高,窗口越小效率越小)
解决思路:稍等一段时间,让接收端程序接收处理缓冲区数据再返回ack

2.捎带应答机制

接收端响应ack,和主动发送的数据,可以合并并返回

3.滑动窗口

1.为什么要有滑动窗口

如果没有滑动窗口,网络数据传输就是串行的方式,效率比较差,使用滑动窗口可以解决效率问题,类似多线程的方式:并发的,同时发送多个数据报

2.实现过程:(这里以窗口大小为4000个字节(四个段)举例说明):

• 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值,上图的滑动窗口就是4000个字节(四个段)
• 发送前四个段的时候,不需要等待任何ack,直接发送
• 收到第一个ack后,滑动窗口向后移动,继续发送第5个段的数据,依次类推
• 操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答,只有确认应答过的数据,才能从缓冲区删掉
• 窗口越大,则网络的吞吐率就越高

3.关于滑动窗口必知必会:

• 窗口大小:无需等待确认应答而可以继续发送数据的最大值
• 如何确定窗口大小:由拥塞窗口和流量控制窗口决定,即滑动窗口大小=min(拥塞窗口大小,流量控制敞口大小)
• 如何滑动:依赖ack的确认序号(ack确认序号前的数据报都已经接收到了),在该ack确认序号前,当次并行接收到多少个数据报,就可以滑动多少
• 发送端为什么要有发送缓冲区:记录已经发送的数据,收到多少ack,才可以清理该数据
• 接收端为什么要有接收缓冲区:记录已经接收的数据,如果发送数据丢失,才知道让对方重发

四.UDP协议

不保证安全，性能比较好

1.UDP协议的特性

• 无连接：知道对端的IP和端口号就直接进行传输，不需要建立连接
• 不可靠，即没有确认应答机制，没有超时重传机制，没有连接管理机制，如果因为网络故障该段无法发到对方，UDP协议层也不会给应用层返回任何错误信息
• 面向数据报，最大不超过64K，不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并
• 具有接收缓冲区，没有发送缓冲区

2.UDP的使用注意事项

UDP协议首部有一个16位的最大长度，也就是说一个UDP能传输的数据最大长度是64K（包含UDP首部），然而64K在当今的互联网环境下，是一个非常小的数字，如果我们需要传输的数据超过64K，就需要在应用层手动的分包，多次发送，并在接收端手动拼装

五.TCP 协议VS UDP协议

1.TCP协议

• 传输层协议
• 有连接
• 可靠传输
• 面向字节流

2.UDP协议

• 传输层协议
• 无连接
• 不可靠传输
• 面向数据报，最大不超过64K

3.场景分析

• TCP用于可靠传输的情况，应用于文件传输，重要状态更新等场景
• UDP用于对高速传输和实时性要求较高的通信领域，例如：早起的QQ、视频传输等，另外UDP可以用于广播

总而言之，TCP和UDP都是程序猿的工具，什么时机用，具体怎么用，还是要根据具体的需求场景去判定

4.TCP与UDP的区别

• TCP是面向连接的，UDP无连接；
• TCP是可靠的，UDP不可靠；TCP只支持点对点的通信；
• UDP支持一对一、一对多、多对一、多对多通信；
• TCP是面向字节流的；UDP是面向报文的；
• TCP首部开销大,20个字节; UDP只有8个字节;
• TCP可以保证传输的数据顺序, UDP不能保证;

六.UDP如何实现可靠

如果要是用UDP实现可靠，那就必须要解决两个问题：丢包和包的顺序问题;在应用层实现

1. 给数据包进行编号，按照包的顺序进行接收并存储；
2. 接收端收到数据包后，发送确认信息给发送端，发送端接收到确认数据后再继续发送下一个包；如果接收端接收到的数据包编号不是预期的编号，则要求发送端重新发送

已经实现了UDP可靠传输的协议：

1. RUDP：可靠数据报传输协议
2. RTP：实时传输协议，为数据提供了具有实时性的端对端传送服务；
3. UDT：互联网传输协议，主要目的是支持高速广域网上的海量数据传输；

七.TCP可能出现的问题—粘包问题

基于传输层TCP来实现应用层协议时,因为TCP是基于字节流,读取时要考虑格式,包括读取多长,如果格式读取不对,或长度没设置好,会出现粘包问题
如何解决:
明确包的边界