计算机网络（TCP篇）-EW帮帮网

TCP 和 UDP

TCP 基本认识

TCP 头格式

在这里插入图片描述

TCP

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

在这里插入图片描述

TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。

TCP 连接

连接定义

在这里插入图片描述

TCP 四元组

TCP 四元组可以唯一的确定一个连接。

在这里插入图片描述

最大 TCP 连接数

在这里插入图片描述

对 IPv4，

客户端的 IP 数最多为 2 的 32 次方
客户端的端口数最多为 2 的 16 次方

服务端单机最大 TCP 连接数约为 2 的 48 次方。

服务端最大并发 TCP 连接数远不能达到理论上限，受文件描述符限制（系统级、用户级、进程级）、文件描述符限制因素影响。

TCP缺陷

在这里插入图片描述

TCP 协议是在内核中实现的，应用程序只能使用不能修改，如果要想升级 TCP 协议，那么只能升级内核。

内核升级涉及到底层软件和运行库的更新，服务程序就需要回归测试是否兼容新的内核版本，所以服务器的内核升级比较保守和缓慢。
基于 TCP 实现的应用协议，都是需要先建立三次握手才能进行数据传输，比如 HTTP 1.0/1.1、HTTP/2、HTTPS。
- TCP 三次握手的延迟被 TCP Fast Open （快速打开）这个特性解决了，这个特性可以在「第二次建立连接」时减少 TCP 连接建立的时延。
- TCP Fast Open 需要服务端和客户端的操作系统同时支持才能体验到，很难被普及开来。
现在大多数网站都是使用 HTTPS 的，这意味着在 TCP 三次握手之后，还需要经过 TLS 四次握手后，才能进行 HTTP 数据的传输，这在一定程序上增加了数据传输的延迟。

针对 HTTPS 来说，TLS 是在应用层实现的握手，而 TCP 是在内核实现的握手，这两个握手过程是无法结合在一起的，总是得先完成 TCP 握手，才能进行 TLS 握手。

在这里插入图片描述

TCP 队头阻塞问题

TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的。
TCP 队头阻塞的问题，其实就是接收窗口的队头阻塞问题。

在这里插入图片描述

eg. 当接收窗口收到的数据不是有序的，比如收到第 33～40 字节的数据，由于第 32 字节数据没有收到，接收窗口无法向前滑动，那么即使先收到第 33～40 字节的数据，这些数据也无法被应用层读取的。

UDP 头部格式

在这里插入图片描述

TCP 和 UDP 区别

在这里插入图片描述

应用场景

在这里插入图片描述

使用同一个端口

TCP & UDP（可以）

传输层的「端口号」的作用，是为了区分同一个主机上不同应用程序的数据包。
传输层有两个传输协议分别是 TCP 和 UDP，在内核中是两个完全独立的软件模块。

多个 TCP 服务进程（不同IP可以）

如果两个 TCP 服务进程同时绑定的 IP 地址和端口都相同，那么执行 bind() 时候就会出错，错误是“Address already in use”。

在这里插入图片描述

因为只要客户端连接的服务器不同，端口资源可以重复使用的。

客户端端口选择的流程

在这里插入图片描述

MTU & MSS

在这里插入图片描述

IP 层进行分片传输，是非常没有效率的。
- 如果一个 IP 分片丢失，整个 IP 报文的所有分片都得重传。
- IP 层本身没有超时重传机制，它由传输层的 TCP 来负责超时和重传。
为了达到最佳的传输效能 TCP 协议在建立连接的时候通常要协商双方的 MSS 值。
- 当 TCP 层发现数据超过 MSS 时，则就先会进行分片，当然由它形成的 IP 包的长度也就不会大于 MTU ，自然也就不用 IP 分片了。
- 经过 TCP 层分片后，如果一个 TCP 分片丢失后，进行重发时也是以 MSS 为单位，而不用重传所有的分片，大大增加了重传的效率。

MSL

MSL 是 Maximum Segment Lifetime，报文最大生存时间，超过这个时间报文将被丢弃。

MSL 与 TTL 的区别

MSL 的单位是时间，而 TTL 是经过路由跳数。
MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TTL 的值一般是 64，Linux 将 MSL 设置为 30 秒，意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒，如果超过了，就认为报文已经消失在网络中了。

TIME_WAIT 等待的时间是 2MSL

网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

QUIC 协议(基于UDP协议实现可靠传输)

Packet Header

重要的字段
在这里插入图片描述
QUIC 也是需要三次握手来建立连接的，主要目的是为了协商连接 ID。

Packet Number

Packet Number 是每个报文独一无二的编号，它是严格递增的。

在这里插入图片描述

QUIC 使用的 Packet Number 单调递增的设计，可以让数据包不再像 TCP 那样必须有序确认，QUIC 支持乱序确认，当数据包Packet N 丢失后，只要有新的已接收数据包确认，当前窗口就会继续向右滑动。

QUIC Frame Header

引入 Frame Header 这一层，通过 Stream ID + Offset 字段信息实现数据的有序性，通过比较两个数据包的 Stream ID 与 Stream Offset ，如果都是一致，就说明这两个数据包的内容一致。
丢失的数据包和重传的数据包 Stream ID 与 Offset 都一致，说明这两个数据包的内容一致。
一个 Packet 报文中可以存放多个 QUIC Frame。

Stream

Stream 类型的 Frame 格式（Stream 可以认为就是一条 HTTP 请求）:
在这里插入图片描述

没有队头阻塞的 QUIC

QUIC 给每一个 Stream 都分配了一个独立的滑动窗口，这样使得一个连接上的多个 Stream 之间没有依赖关系，都是相互独立的，各自控制的滑动窗口。

在这里插入图片描述

QUIC 流量控制

TCP 流量控制是通过让「接收方」告诉「发送方」，它（接收方）的接收窗口有多大，从而让 「发送方」根据「接收方」的实际接收能力控制发送的数据量。

在这里插入图片描述

TCP 连接建立（三次握手过程）

seq：序列号，用于标识TCP报文段的顺序。
ack：确认编号(Acknowledgement Number)，用于确认已接收到的数据字节的序列号。
syn：同步序列编号(Synchronize Sequence Numbers)，用于建立TCP连接的握手过程中的同步标志。

ISN 随机产生

ISN：初始序列号（Inital Sequence Number），连接建立时生成的初始序列号，是客户端随机产生的一个值。

ISN 随机生成算法：

ISN = M + F(localhost, localport, remotehost, remoteport)

M 是一个计时器，这个计时器每隔 4 微秒加 1

F 是一个 Hash 算法，根据源 IP、目的 IP、源端口、目的端口生成一个随机数值

随机数是会基于时钟计时器递增的，基本不可能会随机成一样的初始化序列号。

TCP 连接全过程各种状态

LISTEN：侦听来自远方的TCP端口的连接请求

SYN-SENT：再发送连接请求后等待匹配的连接请求（客户端）

SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认（服务器）

ESTABLISHED：代表一个打开的连接

FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认

FIN-WAIT-2：从远程TCP等待连接中断请求

CLOSE-WAIT：等待从本地用户发来的连接中断请求

CLOSING：等待远程TCP对连接中断的确认

LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认

TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认

CLOSED：没有任何连接状态

在这里插入图片描述

一开始，客户端和服务端都处于 CLOSE 状态。先是服务端主动监听某个端口，处于 LISTEN 状态。

在这里插入图片描述

客户端将第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。

在这里插入图片描述

服务端将第二个报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。

在这里插入图片描述

第三个报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于 ESTABLISHED 状态。
第三次握手是可以携带数据的，前两次握手是不可以携带数据的。

一旦完成三次握手，双方都处于 ESTABLISHED 状态，此时连接就已建立完成，客户端和服务端就可以相互发送数据了。

为什么是“三次”

1. 避免历史连接（主要原因）

三次握手才可以阻止重复历史连接的初始化（主要原因）。

在这里插入图片描述

「旧 SYN 报文」称为历史连接。
TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。

2. 同步双方初始序列号

三次握手才可以同步双方的初始序列号。

TCP 协议的通信双方，都必须维护一个「序列号」，序列号的作用：
在这里插入图片描述

在这里插入图片描述

3. 避免资源浪费

三次握手才可以避免资源浪费。
在这里插入图片描述

两次握手会造成消息滞留情况下，服务端重复接受无用的连接请求 SYN 报文，而造成重复分配资源。\

总结

TCP 建立连接时，通过三次握手能防止历史连接的建立，能减少双方不必要的资源开销，能帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。

不使用「两次握手」和「四次握手」的原因：

「两次握手」：无法防止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
「四次握手」：三次握手就已经理论上最少可靠连接建立，所以不需要使用更多的通信次数。

第一次握手丢失

在这里插入图片描述

tcp_syn_retries：内核参数，控制客户端的 SYN 报文最大重传次数。可以自定义的，默认值一般是 5。
如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发 「超时重传」机制，重传 SYN 报文，而且重传的 SYN 报文的序列号都是一样的 。每次超时的时间是上一次的 2 倍。