小林coding

大家好，我是小林。在上回答了很多人的问题，我发现很多人对 TCP 序列号和确认号的变化都是懵懵懂懂的，只知道三次握手和四次挥手过程中，ACK 报文中确认号要 +1，然后数据传输中 TCP 序列号和确认号的变化就不知道了。也有很多同学跟我反馈，希望我写一篇关于 TCP 序列号和确认号变化过程的文章。大家别小看这个基础知识点，其实很多人都不知道的。所以，这次就跟大家聊聊以下过程中，TCP 序列号和确认号是如何变化的？

大家好，我是小林。有位读者在面试字节时，被问到这么个问题：TCP 三次握手中，客户端收到的第二次握手中 ack 确认号不是自己期望的，会发生什么？是直接丢弃 or 回 RST 报文？

如果「服务端挂掉」指的是「服务端进程崩溃」，服务端的进程在发生崩溃的时候，内核会发送 FIN 报文，与客户端进行四次挥手。但是，如果「服务端挂掉」指的是「服务端主机宕机」，那么是不会发生四次挥手的，具体后续会发生什么？还要看客户端会不会发送数据？如果客户端会发送数据，由于服务端已经不存在，客户端的数据报文会超时重传，当重传总间隔时长达到一定阈值（内核会根据 tcp_retries2 设置的值计算出一个阈值）后，会断开 TCP 连接；

作者：小林coding大家好，我是小林。之前写过 TCP 三次握手和四次挥手过程中，途中某一步的报文丢失会发生什么的文章。当时，主要是文字描述，可能不太好记忆，所以我针对每一步的异常情况，，方便大家理解和记忆。发车！当客户端想和服务端建立 TCP 连接的时候，首先第一个发的就是 SYN 报文，然后进入到SYN_SENT状态。在这之后，如果客户端迟迟收不到服务端的 SYN-ACK 报文（第二次握手），就会触发「超时重传」机制，重传 SYN 报文，而且。...

当被动关闭方在 TCP 挥手过程中，如果「没有数据要发送」，同时「没有开启 TCP_QUICKACK（默认情况就是没有开启，没有开启 TCP_QUICKACK，等于就是在使用 TCP 延迟确认机制）」，那么第二和第三次挥手就会合并传输，这样就出现了三次挥手。所以，出现三次挥手现象，是因为 TCP 延迟确认机制导致的。完！......

大家好，我是小林。这个问题的场景是这样的：客户端通过浏览器向服务端发起 HTTPS 请求时，被「假基站」转发到了一个「中间人服务器」，于是客户端是和「中间人服务器」完成了 TLS 握手，然后这个「中间人服务器」再与真正的服务端完成 TLS 握手。从客户端的角度看，其实并不知道网络中存在中间人服务器这个角色。那么中间人就可以解开浏览器发起的 HTTPS 请求里的数据，也可以解开服务端响应给浏览器的 HTTPS 响应数据。相当于，中间人能够 “偷看” 浏览器与服务端之间的 HTTPS 请求和响应的数据。

TCP 同时打开的情况也类似，只不过从一个客户端变成了两个客户端而已。做个实验。

大家好，我是小林。我记得之前在群里看到，有位读者字节一面的时候被问到：「如何基于 UDP 协议实现可靠传输？」很多同学第一反应就会说把 TCP 可靠传输的特性（序列号、确认应答、超时重传、流量控制、拥塞控制）在应用层实现一遍。实现的思路确实这样没错，但是有没有想过，既然 TCP 天然支持可靠传输，为什么还需要基于 UDP 实现可靠传输呢？这不是重复造轮子吗？所以，我们要先弄清楚 TCP 协议有哪些痛点？而这些痛点是否可以在基于 UDP 协议实现的可靠传输协议中得到改进？在之前这篇文章：TCP 就没什么缺陷吗

作者：小林coding图解计算机基础网站：https://xiaolincoding.com大家好，我是小林。忽然思考一个问题，TCP 通过序列号、确认应答、超时重传、流量控制、拥塞控制等方式实现了可靠传输，看起来它很完美，事实真的是这样吗？TCP 就没什么缺陷吗？所以，今天就跟大家聊聊，TCP 协议有哪些缺陷？主要有四个方面：升级 TCP 的工作很困难；TCP 建立连接的延迟；TCP 存在队头阻塞问题；网络迁移需要重新建立 TCP 连接；接下来，针对这四个方面详细说一下。升级 .

大家好，我是小林。周末的时候，有位读者疑惑为什么 Linux man 手册中关于 netstat 命令中的 tcp listen 状态下的 Recv-Q 和 Send-Q 这两个信息的描述跟我的图解网络写的不一样？我先给大家翻译一下，man 手册是怎么说的：Recv-Q：如果 TCP 连接状态处于 Established，Recv-Q 的数值表示内核中还没拷贝到应用层的数据大小；如果 TCP 连接状态处于 Listen 状态，Recv-Q 的数值表示当前 syn 半连接队列的大小（自内核 2

大家好，我是小林。昨天群里有个读者问了一个很有意思的问题，他抓到一个抓包图，客户端和服务端四次挥手后，客户端在 17 秒内又复用了与上一次连接相同的端口，向服务端发起了 SYN 报文， 并成功建立了连接。他觉得服务端应该还是处于 TIME_WAIT 状态（因为 Linux 操作系统中，2MSL 的时间是 60 秒，也就是 TIME_WAIT 状态的持续时间），为什么收到客户端的 SYN 报文后可以正常建立连接？抓包图手机端不好看，为了方便大家看，我画了一个图：简单来说，这个问题就是，为什么处

大家好，我是小林，我最开始写的第一篇图解文章就是这篇：那时候我也就不到 100 读者，如今这篇阅读都快 2 万了。当时这篇有些地方没有解释到位，然后我周末抽时间把一些没解释清楚的地方重写了，而且还增加 HTTP 缓存技术 方面的面试题，文章的内容相比以前多了 5000 +字和 10 +张图。不多说了，发车发车！HTTP 基本概念HTTP 是什么？HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。能否详细解释「超文本传输协议」？HTTP的名字「超文

有个读者问我，这么个问题：TCP 是面向字节流的协议，UDP 是面向报文的协议？这里的「面向字节流」和「面向报文」该如何理解。如何理解字节流？之所以会说 TCP 是面向字节流的协议，UDP 是面向报文的协议，是因为操作系统对 TCP 和 UDP 协议的发送方的机制不同，也就是问题原因在发送方。先来说说为什么 UDP 是面向报文的协议？当用户消息通过 UDP 协议传输时，操作系统不会对消息进行拆分，在组装好 UDP 头部后就交给网络层来处理，所以发出去的 UDP 报文中的数据部分就是完整的

HTTPS 中 TLS 和 TCP 能同时握手吗？大家好，我是小林。有位读者在面试的时候，碰到这么个问题：面试官跟他说 HTTPS 中的 TLS 握手过程可以同时进行三次握手，然后读者之前看我的文章是说「先进行 TCP 三次握手，再进行 TLS 四次握手」，他跟面试官说了这个，面试官说他不对，他就感到很困惑。我们先不管面试官说的那句「HTTPS 中的 TLS 握手过程可以同时进行三次握手」对不对。但是面试官说「HTTPS 建立连接的过程，先进行 TCP 三次握手，再进行 TLS 四次握手」是错的

tcp_tw_reuse 为什么默认是关闭的？大家好，我是小林。上周有个读者在面试微信的时候，被问到既然打开 net.ipv4.tcp_tw_reuse 参数可以快速复用处于 TIME_WAIT 状态的 TCP 连接，那为什么 Linux 默认是关闭状态呢？好家伙，真的问好细节！当时看到读者这个问题的时候，我也是一脸懵逼的，经过我的一番思考后，终于知道怎么回答这题了。其实这题在变相问「如果 TIME_WAIT 状态持续时间过短或者没有，会有什么问题？」因为开启 tcp_tw_reuse 参数

周末跟朋友讨论了一些 TCP 的问题，在查阅《Linux 服务器高性能编程》这本书的时候，发现书上写了这么一句话：书上说，处于 TIME_WAIT 状态的连接，在收到相同四元组的 SYN 后，会回 RST 报文，对方收到后就会断开连接。书中作者只是提了这么一句话，没有给予源码或者抓包图的证据。起初，我看到也觉得这个逻辑也挺符合常理的，但是当我自己去啃了 TCP 源码后，发现并不是这样的。所以，今天就来讨论下这个问题，「在 TCP 正常挥手过程中，处于 TIME_WAIT 状态的连接，收到相同四元组

大家好，我是小林。今天，聊一个有趣的问题：拔掉网线几秒，再插回去，原本的 TCP 连接还存在吗？可能有的同学会说，网线都被拔掉了，那说明物理层被断开了，那在上层的传输层理应也会断开，所以原本的 TCP 连接就不会存在的了。就好像， 我们拨打有线电话的时候，如果某一方的电话线被拔了，那么本次通话就彻底断了。真的是这样吗？上面这个逻辑就有问题。问题在于，错误的认为拔掉网线这个动作会影响传输层，事实上并不会影响。实际上，TCP 连接在 Linux 内核中是一个名为 struct socket 的结构体，

大家好，我是小林。为什么 TCP 三次握手期间，客户端和服务端的初始化序列号要求不一样的呢？接下来，我一步一步给大家讲明白，我觉得应该有不少人会有类似的问题，所以今天在肝一篇！正文为什么 TCP 三次握手期间，为什么客户端和服务端的初始化序列号要求不一样的呢？主要原因是为了防止历史报文被下一个相同四元组的连接接收。TCP 四次挥手中的 TIME_WAIT 状态不是会持续 2 MSL 时长，历史报文不是早就在网络中消失了吗？是的，如果能正常四次挥手，由于 TIME_WAIT 状态会持续

大家好，我是小林。之前我在图解网络 PDF 里写「TCP 为什么需要三次握手？」，给出了三个原因：三次握手才可以阻止历史连接的初始化（主要原因）；三次握手才可以同步双方的初始序列号；三次握手才可以避免资源浪费；同时，这个内容也在知乎得到了 1000 多赞。其中，在讲第一个原因的时候，提到「三次握手可以通过上下文判断当前连接是否是历史连接，而两次握手无法判断」。因为当时没有详细说为什么两次握手无法判断历史连接，导致有很多读者私信我这个问题。所以，这次详细说一下，顺便给大家复习下，这个面

大家好，我是小林。之前有个读者在秋招面试的时候，被问了这么一个问题：SYN 报文什么时候情况下会被丢弃？好家伙，现在面试都问那么细节了吗？不过话说回来，这个问题跟工作上也是有关系的，因为我就在工作中碰到这么奇怪的时候，客户端向服务端发起了连接，但是连接并没有建立起来，通过抓包分析发现，服务端是收到 SYN 报文了，但是并没有回复 SYN+ACK（TCP 第二次握手），说明 SYN 报文被服务端忽略了，然后客户端就一直在超时重传 SYN 报文，直到达到最大的重传次数。接下来，我就给出我遇到过 SYN

大家好，我是小林。昨晚有位读者问了我这么个问题：大概意思是，一个已经建立的 TCP 连接，客户端中途宕机了，而服务端此时也没有数据要发送，一直处于 establish 状态，客户端恢复后，向服务端建立连接，此时服务端会怎么处理？看过我的图解网络的读者都知道，TCP 连接是由「四元组」唯一确认的。然后这个场景中，客户端的IP、服务端IP、目的端口并没有变化，所以这个问题关键要看客户端发送的 SYN 报文中的源端口是否和上一次连接的源端口相同。1. 客户端的 SYN 报文里的端口号与历史连接不相同

大家好，我是小林。收到个读者的问题，他在面试鹅厂的时候，被搞懵了，因为面试官问了他这么一个网络问题：不得不说，鹅厂真的很喜欢问网络问题，而且爱问异常情况下的网络问题，之前也有篇另外一个读者面试鹅厂的网络问题：「被鹅厂面怕了！」。不过这道鹅厂的网络题可能是提问的读者表述有问题，因为如果 FIN 报文比数据包先抵达客户端，此时 FIN 报文其实是一个乱序的报文，此时客户端的 TCP 连接并不会从 FIN_WAIT_2 状态转换到 TIME_WAIT 状态。因此，我们要关注到点是看「在 FIN_WAI

大家好，我是小林。之前收到个读者的问题，对于 TCP 三次握手和四次挥手的一些疑问：第一次握手，如果客户端发送的SYN一直都传不到被服务器，那么客户端是一直重发SYN到永久吗？客户端停止重发SYN的时机是什么？第三次握手，如果服务器永远不会收到ACK，服务器就永远都留在 Syn-Recv 状态了吗？退出此状态的时机是什么？第三次挥手，如果客户端永远收不到 FIN,ACK，客户端永远停留在 Fin-Wait-2状态了吗？退出此状态时机是什么时候呢？第四次挥手，如果服务器永远收不到 A

图解数字签名和数字证书

大家好，我是小林。我在 csdn 输出了 15w+ 的图解网络系列文章，每一篇文章都有我高清无ma的手绘图。每一篇都相当干活，很多同学跟我说，我的图解网络打破了他们对计算机网络的恐惧，甚至还助力他们进入大厂，每次面试问到网络相关的问题时，一点都不慌！然后问把我的 15 万字的图解系列文章整理成了 PDF ，主要是为了方便，大家阅读目录如下，是不是感觉非常干货！有什么内容？大家肯定第一个关心的就是，这次的图解网络 PDF 相比以前有什么变化呢？首先，最大的变化就是目录结构。你可以从下面这张图

大家好，我是小林。之前有读者问了我这么个问题：大致问题是，TCP 的 Keepalive 和 HTTP 的 Keep-Alive 是一个东西吗？这是个好问题，应该有不少人都会搞混，因为这两个东西看上去太像了，很容易误以为是同一个东西。事实上，这两个完全是两样不同东西，实现的层面也不同：HTTP 的 Keep-Alive，是由应用层（用户态） 实现的，称为 HTTP 长连接；TCP 的 Keepalive，是由 TCP 层（内核态） 实现的，称为 TCP 保活机制；接下来，分别说说它们。

上周有位读者找我说，他在面试腾讯的时候，遇到了这么个问题：这个属于 TCP 异常断开连接的场景，这部分内容在我的「图解网络」还没有详细介绍过，这次就乘着这次机会补一补。这个问题有几个关键词：没有开启 keepalive；一直没有数据交互；进程崩溃；主机崩溃；我们先来认识认识什么是 TCP keepalive 呢？这东西其实就是 TCP 的保活机制，它的工作原理我之前的文章写过，这里就直接贴下以前的内容。如果两端的 TCP 连接一直没有数据交互，达到了触发 TCP 保活机制的条件，

大家好，我是小林，一个专为大家图解的工具人。不管面试 Java 、C/C++、Python 等开发岗位， TCP 的知识点可以说是必问的了。任 TCP 虐我千百遍，我仍待 TCP 如初恋。过去不会没关系，今天就让我们来消除这份恐惧，微笑着勇敢的面对它吧！所以小林整理了关于 TCP 的面试题型，全文共 3 万字 + 100 张图，跟大家一起探讨探讨。1、 TCP 基本认识2、TCP 连接建立3、 TCP 连接断开4、 Socket 编程5、TCP 重传、滑动窗口、流量控制、拥塞控制

HTTP/3 现在还没正式推出，不过自 2017 年起， HTTP/3 已经更新到 34 个草案了，基本的特性已经确定下来了，对于包格式可能后续会有变化。所以，这次 HTTP/3 介绍不会涉及到包格式，只说它的特性。美中不足的 HTTP/2HTTP/2 通过头部压缩、二进制编码、多路复用、服务器推送等新特性大幅度提升了 HTTP/1.1 的性能，而美中不足的是 HTTP/2 协议是基于 TCP 实现的，于是存在的缺陷有三个。队头阻塞；TCP 与 TLS 的握手时延迟；网络迁移需要重新连接；

不多 BB 了，直接发车！一起来看看 HTTP/2 牛逼在哪？HTTP/1.1 协议的性能问题我们得先要了解下 HTTP/1.1 协议存在的性能问题，因为 HTTP/2 协议就是把这些性能问题逐个攻破了。现在的站点相比以前变化太多了，比如：消息的大小变大了，从几 KB 大小的消息，到几 MB 大小的消息；页面资源变多了，从每个页面不到 10 个的资源，到每页超 100 多个资源；内容形式变多样了，从单纯到文本内容，到图片、视频、音频等内容；实时性要求变高了，对页面的实时性要求的应用越来

问你一句：「你知道 HTTP/1.1 该如何优化吗？」我想你第一时间想到的是，使用 KeepAlive 将 HTTP/1.1 从短连接改成长链接。这个确实是一个优化的手段，它是从底层的传输层这一方向入手的，通过减少 TCP 连接建立和断开的次数，来减少了网络传输的延迟，从而提高 HTTP/1.1 协议的传输效率。但其实还可以从其他方向来优化 HTTP/1.1 协议，比如有如下 3 种优化思路：尽量避免发送 HTTP 请求；在需要发送 HTTP 请求时，考虑如何减少请求次数；减少服务器的 HTT

HTTPS 常用的密钥交换算法有两种，分别是 RSA 和 ECDHE 算法。其中，RSA 是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用的。而 ECDHE 算法具有前向安全，所以被广泛使用。我在上一篇已经介绍了 RSA 握手的过程，今天这一篇就「从理论再到实战抓包」介绍 ECDHE 算法。离散对数ECDHE 密钥协商算法是 DH 算法演进过来的，所以我们先从 DH 算法说起。DH 算法是非对称加密算法， 因此它可以用于密钥交换，该算法的核心数学思想是离散对数。是不是

我很早之前写过一篇关于 HTTP 和 HTTPS 的文章，但对于 HTTPS 介绍还不够详细，只讲了比较基础的部分，所以这次我们再来深入一下 HTTPS，用实战抓包的方式，带大家再来窥探一次 HTTPS。对于还不知道对称加密和非对称加密的同学，你先复习我以前的这篇文章「硬核！30 张图解 HTTP 常见的面试题」，本篇文章默认大家已经具备了这些知识。TLS 握手过程HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。所以安

小林写这么多篇图解文章，你们猜我收到的最多的读者问题是什么？没错，就是问我是使用什么画图工具，看来对这一点大家都相当好奇，那干脆不如写一篇介绍下我是怎么画图的。如果我的文章缺少了自己画的图片，相当于失去了灵魂，技术文章本身就很枯燥，如果文章中没有几张图片，读者被劝退的概率飙飙升，剩下没被劝退的估计看着看着就睡着了。所以，精美的图片可以说是必不可少的一部分，不仅在阅读时能带来视觉的冲击，而且图片相比文字能涵盖更多的信息，不然怎会有一图胜千言的说法呢？这时，可能有的读者会说自己不写文章呀，是不是没有必要了解

最近收到不少读者留言，关于怎么学「操作系统」和「计算机网络」的留言，小林写这一块的内容也有半年多了，啃非常多的书，也看了很多视频，有好的有差的，今天就掏心掏肺地分享给大家。

TCP 性能的提升不仅考察 TCP 的理论知识，还考察了对于操心系统提供的内核参数的理解与应用。

前言网上许多博客针对增大 TCP 半连接队列和全连接队列的方式如下：增大 TCP 半连接队列的方式是增大 /proc/sys/net/ipv4/tcp_max_syn_backlog；增大 TCP 全连接队列的方式是增大 listen() 函数中的 backlog；这里先跟大家说下，上面的方式都是不准确的。“你怎么知道不准确？”很简单呀，因为我做了实验和看了 TCP 协议栈的内核源码，发现要增大这两个队列长度，不是简简单单增大某一个参数就可以的。接下来，就会以实战 + 源码分析，带大家

每日一句英语学习，每天进步一点点：前言为了让大家更容易「看得见」 TCP，我搭建不少测试环境，并且数据包抓很多次，花费了不少时间，才抓到比较容易分析的数据包。接下来丢包、乱序、超时重传、快速重传、选择性确认、流量控制等等 TCP 的特性，都能「一览无云」。没错，我把 TCP 的"衣服扒光"了，就为了给大家看的清楚，嘻嘻。正文显形“不可见”的网络包网络世界中的数据包交互我们肉眼是看不见的，它们就好像隐形了一样，我们对着课本学习计算机网络的时候就会觉得非常的抽象，加大了学习的难度。还别说，

前言前段时间，有读者希望我写一篇关于 IP 分类地址、子网划分等的文章，他反馈常常混淆，摸不着头脑。那么，说来就来！而且要盘就盘全一点，顺便挑战下小林的图解功力，所以就来个 IP 基础知识全家桶。吃完这个 IP 基础知识全家桶全家桶，包你撑着肚子喊出：“真香！”不多说，直接上菜，共分为三道菜：首先是前菜 「 IP 基本认识 」其次是主菜 「IP 地址的基础知识」最后是点心 「IP ...

小林我搜集了 5 大类 HTTP 面试常问的题目，同时这 5 大类题跟 HTTP 的发展和演变关联性是比较大的，通过问答 + 图解的形式由浅入深的方式帮助大家进一步的学习和理解 HTTP 。