你从未见过如此详细的 TCP 八股文！
TCP 是一个可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的。
TCP
状态位：SYN 是发起一个连接，ACK 是回复，RST 是重新连接，FIN 是结束连接等。TCP 是面向连接的，因而双方要维护连接的状态。
TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。
面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。并且 TCP 报文是「有序的」，当「前一个」TCP 报文没有收到的时候，即使它先收到了后面的 TCP 报文，那么也不能扔给应用层去处理，同时对「重复」的 TCP 报文会自动丢弃。
UDP
目标和源端口：主要是告诉 UDP 协议应该把报文发给哪个进程。
包长度：该字段保存了 UDP 首部的长度跟数据的长度之和。
校验和：校验和是为了提供可靠的 UDP 首部和数据而设计，防止收到在网络传输中受损的 UDP 包
两者区别
1. 连接
TCP 是面向连接的传输层协议，传输数据前先要建立连接。
UDP 是不需要连接，即刻传输数据。
2. 服务对象
TCP 是一对一的两点服务，即一条连接只有两个端点。
UDP 支持一对一、一对多、多对多的交互通信
3. 可靠性
TCP 是可靠交付数据的，数据可以无差错、不丢失、不重复、按需到达。
UDP 是尽最大努力交付，不保证可靠交付数据。
4. 拥塞控制
TCP 有拥塞控制。
UDP 则没有，即使网络非常拥堵了，也不会影响 UDP 的发送速率。
5. 首部开销
TCP 首部长度较长，会有一定的开销，首部在没有使用「选项」字段时是 20 个字节，如果使用了「选项」字段则会变长的。
UDP 首部只有 8 个字节，并且是固定不变的，开销较小。
6. 传输方式（面向字节流与面向报文）
TCP 是面向字节流的协议，UDP 是面向报文的协议。这是因为操作系统对 TCP 和 UDP 协议的发送方的机制不同。
相关视频讲解：
5000道“八股文”，还需要“死记硬背”吗？90分钟梳理清晰
网络原理tcp、udp，网络编程epoll、reactor，面试中正经“八股文”
C/C++Linux服务器开发高级架构师/C++后台开发架构师免费学习地址
【文章福利】另外还整理一些 C++后台开发架构师 相关学习资料，面试题，教学视频，以及学习路线图，免费分享有需要的可以自行添加：Q群：720209036 点击加入~ 群文件共享
UDP 是面向报文的协议
当用户消息通过 UDP 协议传输时，操作系统不会对消息进行拆分，在组装好 UDP 头部后就交给网络层来处理，所以发出去的 UDP 报文中的数据部分就是完整的用户消息，也就是每个 UDP 报文就是一个用户消息的边界，这样接收方在接收到 UDP 报文后，读一个 UDP 报文就能读取到完整的用户消息。
TCP 是面向字节流的协议
当用户消息通过 TCP 协议传输时，消息可能会被操作系统分组成多个的 TCP 报文，也就是一个完整的用户消息被拆分成多个 TCP 报文进行传输。
这时，接收方的程序如果不知道发送方发送的消息的长度，也就是不知道消息的边界时，是无法读出一个有效的用户消息的，因为用户消息被拆分成多个 TCP 报文后，并不能像 UDP 那样，一个 UDP 报文就能代表一个完整的用户消息。
TCP 粘包
当两个消息的某个部分内容被分到同一个 TCP 报文时，就是我们常说的 TCP 粘包问题，这时接收方不知道消息的边界的话，是无法读出有效的消息。
要解决这个问题，要交给应用程序。
一般有三种方式分包的方式：
固定长度的消息（最简单，但基本不用）
特殊字符作为边界；
自定义消息结构（自定义结构，由包头和数据组成，其中包头包是固定大小的，而且包头里有一个字段来说明紧随其后的数据有多大）
应用场景
由于 TCP 是面向连接，能保证数据的可靠性交付，因此经常用于：
FTP 文件传输；
HTTP / HTTPS；
由于 UDP 面向无连接，它可以随时发送数据，再加上 UDP 本身的处理既简单又高效，因此经常用于：
包总量较少的通信，如 DNS 、SNMP 等；
视频、音频等多媒体通信；
广播通信；
三次握手
一开始，客户端和服务端都处于 CLOSED 状态。先是服务端主动监听某个端口，处于 LISTEN 状态
客户端会随机初始化序号（client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。
服务端收到客户端的 SYN 报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入 client_isn + 1, 接着把 SYN 和 ACK 标志位置为 1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于 SYN-RCVD 状态。
客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部 ACK 标志位置为 1 ，其次「确认应答号」字段填入 server_isn + 1 ，最后把报文发送给服务端，这次报文可以携带客户到服务器的数据，之后客户端处于 ESTABLISHED 状态。
服务器收到客户端的应答报文后，也进入 ESTABLISHED 状态。
第三次握手是可以携带数据的，前两次握手是不可以携带数据的！
为什么是三次
原因一：避免历史连接（首要原因）
客户端连续发送多次 SYN 建立连接的报文，在网络拥堵情况下：
一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；
那么此时服务端就会回一个 SYN + ACK 报文给客户端；
客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。
原因二：同步双方初始序列号
TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：
接收方可以去除重复的数据；
接收方可以根据数据包的序列号按序接收；
可以标识发送出去的数据包中， 哪些是已经被对方收到的（通过 ACK 报文中的序列号知道）；
这样一来一回，才能确保双方的初始序列号能被可靠的同步。
原因三：避免资源浪费
如果只有「两次握手」，当客户端的 SYN 请求连接在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送 SYN ，由于没有第三次握手，服务器不清楚客户端是否收到了自己发送的建立连接的 ACK 确认信号，所以每收到一个 SYN 就只能先主动建立一个连接，这会造成什么情况呢？
如果客户端的 SYN 阻塞了，重复发送多次 SYN 报文，那么服务器在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
四次挥手
客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSED_WAIT 状态。
客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
服务器收到了 ACK 应答报文后，就进入了 CLOSED 状态，至此服务端已经完成连接的关闭。
客户端在经过 2MSL 一段时间后，自动进入 CLOSED 状态，至此客户端也完成连接的关闭。
为什么需要 TIME_WAIT 状态？
主动发起关闭连接的一方，才会有 TIME-WAIT 状态。
需要 TIME-WAIT 状态，主要是两个原因：
防止历史连接中的数据，被后面相同四元组的连接错误的接收，让两个方向上的数据包都被丢弃
保证「被动关闭连接」的一方，能被正确的关闭；
为什么 TIME_WAIT 等待的时间是 2MSL？
MSL 是 报文最大生存时间
MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。
TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 如果被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 FIN 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。
可以看到 2MSL 时长 这其实是相当于至少允许报文丢失一次。比如，若 ACK 在一个 MSL 内丢失，这样被动方重发的 FIN 会在第 2 个 MSL 内到达，TIME_WAIT 状态的连接可以应对。
2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。
重传机制
超时重传
在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据。
当超时时间 RTO 较大时，重发就慢，丢了老半天才重发，没有效率，性能差；
当超时时间 RTO 较小时，会导致可能并没有丢就重发，于是重发的就快，会增加网络拥塞，导致更多的超时，更多的超时导致更多的重发。
超时重传时间 RTO 的值应该略大于报文往返 RTT 的值
如何计算 RTO ？
需要 TCP 通过采样 RTT 的时间，然后进行加权平均，算出一个平滑 RTT 的值，而且这个值还是要不断变化的，因为网络状况不断地变化。
除了采样 RTT，还要采样 RTT 的波动范围，这样就避免如果 RTT 有一个大的波动的话，很难被发现的情况。
如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是超时间隔加倍。
超时周期可能相对较长，于是就可以用「快速重传」机制来解决超时重发的时间等待。
快速重传
不以时间为驱动，而是以数据驱动重传。
快速重传的工作方式是当收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。
快速重传机制只解决了超时时间的问题，但是它依然面临着另外一个问题。就是重传的时候，是重传一个，还是重传所有的问题。
SACK 选择性确认
在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将已收到的数据的信息发送给「发送方」，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。
D-SACK
使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。
好处：可以让「发送方」知道，是发出去的包丢了，还是接收方回应的 ACK 包丢了，还是「发送方」的数据包被网络延迟了;
滑动窗口
我们都知道 TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了， 再发送下一个。
这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。
窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
窗口大小由哪一方决定？
通常窗口的大小是由接收方的窗口大小来决定的。
发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。
发送方的滑动窗口
滑动窗口方案使用三个指针来跟踪在四个传输类别中的每一个类别中的字节。其中两个指针是绝对指针（指特定的序列号），一个是相对指针（需要做偏移）。
SND.WND：表示发送窗口的大小（由接收方指定的）；
SND.UNA（Send Unacknoleged）：绝对指针，它指向的是已发送但未收到确认的第一个字节的序列号，也就是 #2 的第一个字节。
SND.NXT：绝对指针，它指向未发送但可发送范围的第一个字节的序列号，也就是 #3 的第一个字节。
指向 #4 的第一个字节是个相对指针，它需要 SND.UNA 指针加上 SND.WND 大小的偏移量，就可以指向 #4 的第一个字节了。
接收方的滑动窗口
两个指针进行划分:
RCV.WND：表示接收窗口的大小，它会通告给发送方。
RCV.NXT：绝对指针，它指向期望从发送方发送来的下一个数据字节的序列号，也就是 #3 的第一个字节。
指向 #4 的第一个字节是个相对指针，它需要 RCV.NXT 指针加上 RCV.WND 大小的偏移量，就可以指向 #4 的第一个字节了。
接收窗口和发送窗口的大小是相等的吗？
约等于
因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。
流量控制
流量控制是避免发送方数据填满接收方的缓存。
滑动窗口所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。
当应用进程没办法及时读取缓冲区的内容时，也会对我们的缓冲区造成影响。
如果先减少缓存，再收缩窗口，发送方依旧传输大量数据，就会出现丢包的现象。
窗口关闭
如果接收方非 0 窗口通知丢失，发送方一直等待接收方的非 0 窗口通知，接收方也一直等待发送方的数据，如不采取措施，这种相互等待的过程，会造成了死锁的现象。
只要 TCP 连接一方收到对方的零窗口通知，就启动持续计时器。
如果持续计时器超时，就会发送窗口探测报文。如果接收窗口仍然为 0，那么收到这个报文的一方就会重新启动持续计时器。
窗口探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。
糊涂窗口综合症
如果接收方太忙了，来不及取走接收窗口里的数据，那么就会导致发送方的发送窗口越来越小。
到最后，如果接收方腾出几个字节并告诉发送方现在有几个字节的窗口，而发送方会义无反顾地发送这几个字节，这就是糊涂窗口综合症。
我们的 TCP + IP 头有 40 个字节，为了传输那几个字节的数据，要达上这么大的开销，这太不经济了。
让接收方不通告小窗口给发送方
让发送方避免发送小数据
接收方
当 窗口大小 小于 最大报文长度 与 1/2 缓存大小中的最小值时，就会向发送方通告窗口为 0，也就阻止了发送方再发数据过来。
发送方
延时处理：只有满足下面两个条件中的任意一个条件，才能可以发送数据：
条件一：要等到窗口大小或者数据大小 >= 最大报文长度
条件二：收到之前发送数据的 ack 包；
拥塞控制
目的是避免发送方数据填满整个网络。
拥塞窗口
拥塞窗口是发送方决定的，它会根据网络的拥塞程度变化的。
发送窗口的值是拥塞窗口和接收窗口中的最小值。
拥塞控制有哪些控制算法？ 慢启动
慢启动的意思就是一点一点的提高发送数据包的数量。
算法规则：当发送方每收到一个 ACK，拥塞窗口大小就会加 1。
慢启动算法，发包的个数呈指数性增长。
那慢启动涨到什么时候是个头呢？
有一个叫慢启动门限 ssthresh 状态变量。
当 拥塞窗口 < 慢启动门限 时，使用慢启动算法。
当 拥塞窗口 >= 慢启动门限 时，就会使用拥塞避免算法
拥塞避免算法
算法规则是：每当收到一个 ACK 时，拥塞窗口 增加 1/拥塞窗口。
变成了线性增长
网络慢慢进入拥塞状况，就会出现丢包现象，然后重传。
当触发了重传机制，也就进入了拥塞发生算法。
拥塞发生
主要的重传机制：
超时重传
快速重传
发生超时重传的拥塞发生算法
当发生了「超时重传」，则就会使用拥塞发生算法。
这个时候，慢启动门限 和 拥塞窗口 的值会发生变化：
慢启动门限 设为 拥塞窗口/2，
拥塞窗口 重置为初始值
发生快速重传的拥塞发生算法
发生快速重传时 TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则 慢启动门限 和 拥塞窗口 变化如下：
慢启动门限和拥塞窗口值变为当前拥塞窗口的一半
进入快速恢复算法
快速恢复
快速重传和快速恢复同时使用
快速恢复算法如下：
拥塞窗口 = 慢启动门限 + 3 （发送方收到 3 个重复确认，说明 3 个报文已经离开网络，到了接收方的缓存中，所以调大了拥塞窗口）；
重传丢失的数据包；
如果再收到重复的 ACK，那么拥塞窗口值加 1；
如果收到新数据的 ACK 后，把拥塞窗口值设置为慢启动门限值，原因是该 ACK 确认了新的数据，说明丢失的数据包已收到，快速恢复过程结束，再次进入拥塞避免状态；
没有像超时重传一夜回到解放前，而是还在比较高的值，后续呈线性增长。
后续还会更新一些你可能没见过的 HTTP、TCP 面试题，点赞支持一下吧~
原文地址：你从未见过如此详细的 TCP 八股文！
C/C++后台开发技术交流qun：720209036 2022.05.06 加入
还未添加个人简介
评论