看完把学霸按在地上摩擦，计算机网络知识点总结（3）——TCP部分

文章已经全部写好了，但是要参加活动，然后再搞上链接之类的导致有时间差，等一下就把链接补回来。

阿伟在学完了《计算机网络：自顶向下的办法》以及《TCP/IP详解：卷一协议（原书第二版)》感觉学的还不是特别好，感觉做题的时候，我简直人都傻了，写个文章、用表格的形式、做题目的形式对计算机网络比较常见的一些知识点进行总结，希望在自己成长的同时，可以帮助到有需要的人。

该文章是看了超级多的知乎专栏、CSDN文章等做的总结。题目来源以及题目后面所附代的参考文章的具体网址，会放在另外一个文章里面，以此来节省篇幅。

以上两本书私聊可以给电子书。

总体而言，将计算网络的知识点总结分为五个文章，总共18个小点，建议按着点来学习：

1. 《计算机网络的杂项，比如说什么网关之类的》
   ，网址：https://blog.csdn.net/qq_45877524/article/details/105904241
2. 《TCP的工具人协议》
   ，网址：https://blog.csdn.net/qq_45877524/article/details/105904318
3. 《TCP部分》，网址：https://blog.csdn.net/qq_45877524/article/details/105904354
4. 《题目》，网址：https://blog.csdn.net/qq_45877524/article/details/105904417
5. 《整个文章中用到的参考资料，网址：https://blog.csdn.net/qq_45877524/article/details/105886501)》

最后有一个打印版本，方便复习：《组合版本》
https://blog.csdn.net/qq_45877524/article/details/105886463

---

---

13. UDP协议解释、TCP和UDP之间的区别

UDP这个属于非常底层的东西，基本上都已经很少用到了，基本上题目更加多问的是TCP与UDP之间的区别，以此考察TCP。

UDP是User Datagram Protocol的简称，中文名是用户数据报协议，是OSI参考模型中的传输层协议，它是一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。
UDP的正式规范是IETF RFC768。UDP在IP报文的协议号是17。

老规矩，UDP不过多介绍，具体讲解可以看下面几个文章：

1. CSDN博主[Object object]的《TCP 和 UDP 的区别》，网址：https://blog.csdn.net/zhang6223284/article/details/81414149?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-2
2. CSDN博主李大坝超欧的的《UDP协议的详细解析》，网址：https://blog.csdn.net/aa1928992772/article/details/85240358
3. CSDN博主china_jeffery的《网络协议 – UDP协议（1）介绍》，网址：https://blog.csdn.net/china_jeffery/article/details/78923428
4. CSDN博主彪悍的男人的《玩转wireshark系列第三篇-抓取udp包》，网址：https://blog.csdn.net/u011416247/article/details/80868133?depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1&utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1
5. CSDN博主一日思考的《UDP协议学习》，网址：https://blog.csdn.net/s_lisheng/article/details/73538229?depth_1-utm_source=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-3&utm_source=distribute.pc_relevant_right.none-task-blog-BlogCommendFromMachineLearnPai2-3

---

第一个比较详细，第三个比较简略但是足够了。

特征点	TCP	UDP
是否连接	面向连接	面向非连接
传输可靠性	可靠	会丢包，不可靠
应用场景	传输数据量大	传输量小
速度	慢	快

参考了： CSDN博主china_jeffery

---

14. TCP首部报文结构

我感觉这个东西不是特别重要，重要的是IPv4之类的这里就水一波。

具体讲解：博客园博主 zzfx的《TCP报文格式详解》，网址：https://www.cnblogs.com/feng9exe/p/8058891.html

15. TCP的三次握手以及四次挥手

哇，这年头如果面试还回答不出来TCP的三次握手和四次挥手是个什么东西，那估计可以被直接抬走了，那简直就是直接在面试官的嘴里面塞个电饭煲。

整个好活，提一下神

B站up主比划比划鬼畜网的视频《黑人抬棺原版视频》，网址：https://www.bilibili.com/video/BV1NZ4y1j7nw?from=search&seid=12079556593468117240

---

言归正传，这个东西真的很重要，确实也是非常非常基础。最好还是搞个十分正经的文章去复习一下，可以看我的装载文章：
《动画解决TCP 三次握手与四次挥手（附十道面试题)(装载）》，网址：https://blog.csdn.net/qq_45877524/article/details/105723587

最主要是找了一些题目比较方便理解。

---

有部分内容装载至CSDN博主 青柚_的《TCP的三次握手与四次挥手理解及面试题（很全面）》，网址：https://blog.csdn.net/qq_38950316/article/details/81087809

有部分内容装载至知乎用户低端叫兽在的回答《关于三次握手和四次挥手，面试官想听到怎样的回答？》，网址：https://www.zhihu.com/question/271701044

15.1 为什么客户端最后还要等待2MSL？（CSDN博主 小书go）

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

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

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

–

15.2 如果已经建立了连接，但是客户端突然出现故障了怎么办？（CSDN博主 小书go）

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

---

15.3 为什么不能用两次握手进行连接？（CSDN博主 青柚_）

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。

现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

---

15.4 如果已经建立了连接，但是客户端突然出现故障了怎么办？（CSDN博主 青柚_）

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

---

15.5 为什么关闭连接要设计成四次？(低端叫兽)

因为关闭连接时，server端收到客户端的fin报文，并不会立即关闭socket，只能先回复一个ack告诉client我已经收到你的关闭请求了，同时可能server还有数据没传输完，只有等server端数据传输完成了 才能发送fin报文，所以这个地方要分两次发送，这样就有了四次挥手.

---

15.6 服务端运行一段时间后，套接字出现了大量的Close_Wait状态，最有可能是什么原因导致的？(低端叫兽)

close-wait状态是因为client已经发出释放连接信号了 已经没有数据传输过来，但是server端还有数据未发送完，这个时候就有close-wait状态了！

---

15.7 为什么基于TCP的程序往往都有个应用层的心跳检测机制？(低端叫兽)

是为了预防建立好的连接突然客户端故障了，服务器不能一直等待下去，需要一个计时器和探测包来检测.

---

15.8 服务端的Time_Wait状态再哪个阶段出现？持续多久？为什么要设计这么一个状态？(低端叫兽)

timewait阶段是最后阶段发送确认收到server端的fin报文释放连接请求后回复给server端ack报文，之后client端就进入time_wait阶段.

持续多久即是问为什么不马上关闭直接进入closed阶段，主要是考虑到网络的不可靠，假如client最后阶段发送给server端端ack报文由于网络原因丢失了server没收到呢，server端会重新发送fin报文过来，这个时候client端就要等.

等多久？等一个计时器时间2MSL，如果该时间段内再次收到server的fin报文 那client就必须回复. 如果没有收到，client就认为server端已经接收到了最后的ack报文.

---

16. TCP滑动窗口与拥塞机制

这个东西的重要性比不上三次握手、四次挥手，但是考题中也会遇到。

16.1 TCP滑动窗口

b站上有一个视频比较nice的可视化了滑动窗口的机制。

tcp滑动窗口的完美解释

来自于up主 今天单词背了吗O_o 的tcp滑动窗口的完美解释，网址：https://www.bilibili.com/video/BV1FE411C7dk?from=search&seid=6007213953266071805
这里可以看我的装载文章：
《TCP之滑动窗口协议(动画演示)（装载）》，网址：https://blog.csdn.net/qq_45877524/article/details/105854591

16.2 TCP拥塞机制

自我检讨这个东西确实不熟，回首掏的时候补上。

还是贴出几个文章链接吧：

1. CSDN博主sHuXnHs的 《TCP拥塞控制机制（附面试题）》，网址：https://blog.csdn.net/shuxnhs/article/details/80644531
2. CSDN博主lt_李木子的《TCP的拥塞控制（详解）》，网址：https://blog.csdn.net/qq_41431406/article/details/97926927?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-1
3. CSDN博主sicofield的《TCP的拥塞控制》，网址：https://blog.csdn.net/sicofield/article/details/9708383?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromBaidu-3

第一个的腾讯题目很nice，但是讲的地方会有部分错误，第二个没什么问题没有题目熟悉

参考资料：

《整个文章中用到的参考资料，网址：https://blog.csdn.net/qq_45877524/article/details/105886501)》