[计算机网络] TCP和UDP

TCP报文

• 源端口
• 目的端口
• 序号
• 确认号
• 数据偏移：数据偏移还有个名称也叫首部长度，因为TCP首部是长度可变的，这个报文段到底多长，也就是说指出TCP数据部分在整个TCP报文段的什么位置。
• 状态位，SYN发起联机，ACK回复，RST重新联机，FIN结束联机等。
• 窗口：告知发送端这个接收端缓存有多少，控制发送端发送数据的速率，达到流量控制。
• 检验和：对整个TCP报文段来说，TCP首部和数据在发送端和接收端之间发生任何的改动，接收方检验有差错，这个TCP段就会被直接丢弃。
• 紧急指针:它要配合标志位URG一起使用。TCP就知道你要发送紧急数据
• 选项部分：最长报文大小，接收方或发送方所能接受的最大报文段的长度。
• 填充：选项部分如果不是32位的整数倍，要添加填充位，加入额外的零，保证TCP头是32的整数倍。
• 数据部分： TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时，双方交换的报文段仅有 TCP 首部。如果一方没有数据要发送，也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中，也会发送不带任何数据的报文段。

TCP和UDP协议

UDP：不可靠，无连接，时延小，适用于小文件
TCP：面向连接，时延大，适用于大文件；确保可靠性：三次握手，超时重传，滑动窗口，拥塞控制。

• TCP协议中包含了专门的传递保证机制，当数据接收方收到发送方传来的信息时，会自动向发送方发出确认消息；发送方只有在接收到该确认消息之后才继续传送其它信息，否则将一直等待直到收到确认信息为止。 与TCP不同，UDP协议并不提供数据传送的保证机制。如果在从发送方到接收方的传递过程中出现数据报的丢失，协议本身并不能做出任何检测或提示。
• UDP具有TCP所望尘莫及的速度优势。虽然TCP协议中植入了各种安全保障功能，但是在实际执行的过程中会占用大量的系统开销，无疑使速度受到严重的影响。反观UDP由于排除了信息可靠传递机制，将安全和排序等功能移交给上层应用来完成，极大降低了执行时间，使速度得到了保证。

TCP三次握手

过程

1. 主机 A 向主机 B 发送 TCP 连接请求数据包，其中包含主机 A 的初始序列号 seq(A)=x。（其中报文中同步标志位 SYN=1，ACK=0，表示这是一个 TCP 连接请求数据报文；序号 seq=x，表明传输数据时的第一个数据字节的序号是 x）；
2. 主机 B 收到请求后，会发回连接确认数据包。（其中确认报文段中，标识位 SYN=1，ACK=1，表示这是一个 TCP 连接响应数据报文，并含主机 B 的初始序列号 seq(B)=y，以及主机 B 对主机 A初始序列号的确认号 ack(B)=seq(A)+1=x+1）
3. 第三次，主机 A 收到主机 B 的确认报文后，还需作出确认，即发送一个序列号 seq(A)=x+1；确认号为 ack(A)=y+1 的报文；

三次握手为什么不用两次?

• 主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送的第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的费。
• 如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为什么不用四次?

• 因为三次已经可以满足需要了, 四次就多余了.

TCP四次挥手

过程

1. 关闭客户端到服务器的连接：首先客户端 A 发送一个 FIN，用来关闭客户到服务器的数据传送，然后等待服务器的确认。其中终止标志位 FIN=1，序列号 seq=u。
2. 服务器收到这个 FIN，它发回一个 ACK，确认号 ack 为收到的序号加 1。
3. 关闭服务器到客户端的连接：也是发送一个 FIN 给客户端。
4. 客户段收到 FIN 后，并发回一个 ACK 报文确认，并将确认序号 seq 设置为收到序号加1。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

为什么最后客户端还要等待 2*MSL的时间呢?

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

• 第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

• 第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

• 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接, 但是客户端突发故障了怎么办?

• TCP设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP超时重传

TCP滑动窗口

TCP拥塞控制

四种算法

• 慢开始
• 拥塞避免
• 快重传
• 快恢复

慢开始和拥塞避免

这里开始时以指数形式增长，ssthresh的意思是慢开始门限，代表从这个地方注入的报文段就比较多了，需要开始慢速增加了。
之后一段都是线性增长，每次增加1，直至达到网络拥塞状态
瞬间将cwnd设置为1，同时调整原来的ssthresh的值到之前达到网络拥塞状态的1/2,（这里是24降到12）
重复以上步骤，但是注意此时ssthresh变了之后线性增长的转折点也变了

快重传和快恢复

这里和上面的慢开始和拥塞避免的一开始步骤差不多，都是先指数增长再转变为线性增长。
不同的点是快重传和快恢复算法是在收到连续的ack确认之后执行，这里的ack就是冗余ack，冗余ack的特点是如果多次对某一段请求的数据没有被收到，达到一定数目之后就会立即执行重传。但是此时只是降到现在cwnd的一半，再重新线性增长。而不是像慢开始和拥塞避免的从头开始

TCP粘包

https://www.pianshen.com/article/12831205867/

什么是TCP粘包

TCP 是一个流式传输协议，而且每个数据包的长度是不固定的，

粘包发生在发送或接收缓冲区中；应用程序从缓冲区中取数据是整个缓冲区中有多少取多少；那么就有可能第一个数据的尾部和第二个数据的头部同时存在缓冲区，而TCP是流式的，数据无边界，这时发生粘包。

产生原因

1.发送方产生粘包

采用TCP协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据；但当发送的数据包过于的小时，那么TCP协议默认的会启用Nagle算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了；

2.接收方产生粘包

我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包；（放数据的速度 > 应用层拿数据速度）

解决办法

1. 发送产生是因为Nagle算法合并小数据包，那么可以禁用掉该算法；
2. 目前应用最广泛的是在消息的头部添加数据包长度，接收方根据消息长度进行接收；
3. 自定义数据格式：在数据中放入开始、结束标识；解析时根据格式抓取数据，缺点是数据内不能含有开始或结束标识；
4. 短连接传输，建立一次连接只传输一次数据就关闭；（不推荐）