作为后端开发人员应该懂的 TCP、HTTP、Socket、Socket 连接池，一文详解丨 Linux 后端开发

关注

发布于: 2021 年 03 月 25 日

前言：作为一名开发人员我们经常会听到 HTTP 协议、TCP/IP 协议、UDP 协议、Socket、Socket 长连接、Socket 连接池等字眼，然而它们之间的关系、区别及原理并不是所有人都能理解清楚，这篇文章就从网络协议基础开始到 Socket 连接池，一步一步解释他们之间的关系。

文章比较长建议收藏点赞观看，文末有惊喜哦~~

七层网络模型

首先从网络通信的分层模型讲起：七层模型，亦称 OSI(Open System Interconnection)模型。自下往上分为：物理层、据链路层、网络层、传输层、会话层、表示层和应用层。所有有关通信的都离不开它，下面这张图片介绍了各层所对应的一些协议和硬件。

通过上图，我知道 IP 协议对应于网络层，TCP、UDP 协议对应于传输层，而 HTTP 协议对应于应用层，OSI 并没有 Socket，那什么是 Socket，后面我们将结合代码具体详细介绍。

TCP 和 UDP 连接

关于传输层 TCP、UDP 协议可能我们平时遇见的会比较多，有人说 TCP 是安全的，UDP 是不安全的，UDP 传输比 TCP 快，那为什么呢，我们先从 TCP 的连接建立的过程开始分析，然后解释 UDP 和 TCP 的区别。

TCP 的三次握手和四次分手

我们知道 TCP 建立连接需要经过三次握手，而断开连接需要经过四次分手，那三次握手和四次分手分别做了什么和如何进行的。

第一次握手:建立连接。客户端发送连接请求报文段，将 SYN 位置为 1，Sequence Number 为 x；然后，客户端进入 SYN_SEND 状态，等待服务器的确认；

第二次握手:服务器收到客户端的 SYN 报文段，需要对这个 SYN 报文段进行确认，设置 Acknowledgment Number 为 x+1(Sequence Number+1)；同时，自己自己还要发送 SYN 请求信息，将 SYN 位置为 1，Sequence Number 为 y；服务器端将上述所有信息放到一个报文段（即 SYN+ACK 报文段）中，一并发送给客户端，此时服务器进入 SYN_RECV 状态；

第三次握手:客户端收到服务器的 SYN+ACK 报文段。然后将 Acknowledgment Number 设置为 y+1，向服务器发送 ACK 报文段，这个报文段发送完毕以后，客户端和服务器端都进入 ESTABLISHED 状态，完成 TCP 三次握手。

完成了三次握手，客户端和服务器端就可以开始传送数据。以上就是 TCP 三次握手的总体介绍。通信结束客户端和服务端就断开连接，需要经过四次分手确认。

第一次分手：主机 1（可以使客户端，也可以是服务器端），设置 Sequence Number 和 Acknowledgment Number，向主机 2 发送一个 FIN 报文段；此时，主机 1 进入 FIN_WAIT_1 状态；这表示主机 1 没有数据要发送给主机 2 了；

第二次分手：主机 2 收到了主机 1 发送的 FIN 报文段，向主机 1 回一个 ACK 报文段，Acknowledgment Number 为 Sequence Number 加 1；主机 1 进入 FIN_WAIT_2 状态；主机 2 告诉主机 1，我“同意”你的关闭请求；

第三次分手：主机 2 向主机 1 发送 FIN 报文段，请求关闭连接，同时主机 2 进入 LAST_ACK 状态；

第四次分手：主机 1 收到主机 2 发送的 FIN 报文段，向主机 2 发送 ACK 报文段，然后主机 1 进入 TIME_WAIT 状态；主机 2 收到主机 1 的 ACK 报文段以后，就关闭连接；此时，主机 1 等待 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，主机 1 也可以关闭连接了。

可以看到一次 tcp 请求的建立及关闭至少进行 7 次通信，这还不包过数据的通信，而 UDP 不需 3 次握手和 4 次分手。

分享更多关于 Linux 后端开发网络底层原理知识学习提升点击 学习资料 获取，完善技术栈，内容知识点包括 Linux，Nginx，ZeroMQ，MySQL，Redis，线程池，MongoDB，ZK，Linux 内核，CDN，P2P，epoll，Docker，TCP/IP，协程，DPDK 等等。

TCP 和 UDP 的区别

TCP 是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但 TCP 的三次握手在最低限度上(实际上也很大程度上保证了)保证了连接的可靠性;而 UDP 不是面向连接的，UDP 传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说 UDP 是无连接的、不可靠的一种数据传输协议。
也正由于 1 所说的特点，使得 UDP 的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以 UDP 的实时性更好。知道了 TCP 和 UDP 的区别，就不难理解为何采用 TCP 传输协议的 MSN 比采用 UDP 的 QQ 传输文件慢了，但并不能说 QQ 的通信是不安全的，因为程序员可以手动对 UDP 的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP 因为在底层协议的封装上没有采用类似 TCP 的“三次握手”而实现了 TCP 所无法达到的传输效率。

问题

关于传输层我们会经常听到一些问题

1．TCP 服务器最大并发连接数是多少？

关于 TCP 服务器最大并发连接数有一种误解就是“因为端口号上限为 65535,所以 TCP 服务器理论上的可承载的最大并发连接数也是 65535”。首先需要理解一条 TCP 连接的组成部分：客户端 IP、客户端端口、服务端 IP、服务端端口。所以对于 TCP 服务端进程来说，他可以同时连接的客户端数量并不受限于可用端口号，理论上一个服务器的一个端口能建立的连接数是全球的 IP 数*每台机器的端口数。实际并发连接数受限于 linux 可打开文件数，这个数是可以配置的，可以非常大，所以实际上受限于系统性能。通过 #ulimit -n 查看服务的最大文件句柄数，通过 ulimit -n xxx 修改 xxx 是你想要能打开的数量。也可以通过修改系统参数：

2．为什么 TIME_WAIT 状态还需要等 2MSL 后才能返回到 CLOSED 状态？

这是因为虽然双方都同意关闭连接了，而且握手的 4 个报文也都协调和发送完毕，按理可以直接回到 CLOSED 状态（就好比从 SYN_SEND 状态到 ESTABLISH 状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的 ACK 报文会一定被对方收到，因此对方处于 LAST_ACK 状态下的 Socket 可能会因为超时未收到 ACK 报文，而重发 FIN 报文，所以这个 TIME_WAIT 状态的作用就是用来重发可能丢失的 ACK 报文。

3．TIME_WAIT 状态还需要等 2MSL 后才能返回到 CLOSED 状态会产生什么问题

通信双方建立 TCP 连接后，主动关闭连接的一方就会进入 TIME_WAIT 状态，TIME_WAIT 状态维持时间是两个 MSL 时间长度，也就是在 1-4 分钟，Windows 操作系统就是 4 分钟。进入 TIME_WAIT 状态的一般情况下是客户端，一个 TIME_WAIT 状态的连接就占用了一个本地端口。一台机器上端口号数量的上限是 65536 个，如果在同一台机器上进行压力测试模拟上万的客户请求，并且循环与服务端进行短连接通信，那么这台机器将产生 4000 个左右的 TIME_WAIT Socket，后续的短连接就会产生 address already in use : connect 的异常，如果使用 Nginx 作为方向代理也需要考虑 TIME_WAIT 状态，发现系统存在大量 TIME_WAIT 状态的连接，通过调整内核参数解决。

编辑文件，加入以下内容：

然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启 SYN Cookies。当出现 SYN 等待队列溢出时，启用 cookies 来处理，可防范少量 SYN 攻击，默认为 0，表示关闭；

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接，默认为 0，表示关闭；

net.ipv4.tcp_tw_recycle = 1 表示开启 TCP 连接中 TIME-WAIT sockets 的快速回收，默认为 0，表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间。

HTTP 协议

关于 TCP/IP 和 HTTP 协议的关系，网络有一段比较容易理解的介绍：“我们在传输数据时，可以只使用(传输层)TCP/IP 协议，但是那样的话，如果没有应用层，便无法识别数据内容。如果想要使传输的数据有意义，则必须使用到应用层协议。应用层协议有很多，比如 HTTP、FTP、TELNET 等，也可以自己定义应用层协议。

HTTP 协议即超文本传送协议(Hypertext Transfer Protocol )，是 Web 联网的基础，也是手机联网常用的协议之一，WEB 使用 HTTP 协议作应用层协议，以封装 HTTP 文本信息，然后使用 TCP/IP 做传输层协议将它发到网络上。

由于 HTTP 在每次请求结束后都会主动释放连接，因此 HTTP 连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开。

下面是一个简单的 HTTP Post application/json 数据内容的请求：

关于 Socket（套接字）

现在我们了解到 TCP/IP 只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如 Win32 编程接口一样，TCP/IP 也必须对外提供编程接口，这就是 Socket。现在我们知道，Socket 跟 TCP/IP 并没有必然的联系。Socket 编程接口在设计的时候，就希望也能适应其他的网络协议。所以，Socket 的出现只是可以更方便的使用 TCP/IP 协议栈而已，其对 TCP/IP 进行了抽象，形成了几个最基本的函数接口。比如 create，listen，accept，connect，read 和 write 等等。

不同语言都有对应的建立 Socket 服务端和客户端的库，下面举例 Nodejs 如何创建服务端和客户端：

服务端：

服务监听 9000 端口

下面使用命令行发送 http 请求和 telnet

注意到 curl 只处理了一次报文。

客户端

Socket 长连接

所谓长连接，指在一个 TCP 连接上可以连续发送多个数据包，在 TCP 连接保持期间，如果没有数据包发送，需要双方发检测包以维持此连接(心跳包)，一般需要自己做在线维持。短连接是指通信双方有数据交互时，就建立一个 TCP 连接，数据发送完成后，则断开此 TCP 连接。比如 Http 的，只是连接、请求、关闭，过程时间较短,服务器若是一段时间内没有收到请求即可关闭连接。其实长连接是相对于通常的短连接而说的，也就是长时间保持客户端与服务端的连接状态。

通常的短连接操作步骤是：

连接→数据传输→关闭连接；

而长连接通常就是：

连接→数据传输→保持连接(心跳)→数据传输→保持连接(心跳)→……→关闭连接；

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个 TCP 连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就 OK 了，不用建立 TCP 连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成 Socket 错误，而且频繁的 Socket 创建也是对资源的浪费。

什么是心跳包为什么需要：

心跳包就是在客户端和服务端间定时通知对方自己状态的一个自己定义的命令字，按照一定的时间间隔发送，类似于心跳，所以叫做心跳包。网络中的接收和发送数据都是使用 Socket 进行实现。但是如果此套接字已经断开（比如一方断网了），那发送数据和接收数据的时候就一定会有问题。可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。其实 TCP 中已经为我们实现了一个叫做心跳的机制。如果你设置了心跳，那 TCP 就会在一定的时间（比如你设置的是 3 秒钟）内发送你设置的次数的心跳（比如说 2 次），并且此信息不会影响你自己定义的协议。也可以自己定义，所谓“心跳”就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己“在线”,以确保链接的有效性。

实现：

服务端：

服务端输出结果：

客户端代码：

客户端输出结果：

定义自己的协议

如果想要使传输的数据有意义，则必须使用到应用层协议比如 Http、Mqtt、Dubbo 等。基于 TCP 协议上自定义自己的应用层的协议需要解决的几个问题：

心跳包格式的定义及处理
报文头的定义，就是你发送数据的时候需要先发送报文头，报文里面能解析出你将要发送的数据长度
你发送数据包的格式，是 json 的还是其他序列化的方式

下面我们就一起来定义自己的协议，并编写服务的和客户端进行调用：

定义报文头格式： length:000000000xxxx; xxxx 代表数据的长度，总长度 20,举例子不严谨。

数据序列化方式：JSON。

服务端:

日志打印：

客户端

日志打印：

这里可以看到一个客户端在同一个时间内处理一个请求可以很好的工作，但是想象这么一个场景，如果同一时间内让同一个客户端去多次调用服务端请求，发送多次头数据和内容数据，服务端的 data 事件收到的数据就很难区别哪些数据是哪次请求的，比如两次头数据同时到达服务端，服务端就会忽略其中一次，而后面的内容数据也不一定就对应于这个头的。所以想复用长连接并能很好的高并发处理服务端请求，就需要连接池这种方式了。

Socket 连接池

什么是 Socket 连接池,池的概念可以联想到是一种资源的集合，所以 Socket 连接池，就是维护着一定数量 Socket 长连接的集合。它能自动检测 Socket 长连接的有效性，剔除无效的连接，补充连接池的长连接的数量。从代码层次上其实是人为实现这种功能的类，一般一个连接池包含下面几个属性：

空闲可使用的长连接队列
正在运行的通信的长连接队列
等待去获取一个空闲长连接的请求的队列
无效长连接的剔除功能
长连接资源池的数量配置
长连接资源的新建功能

场景：一个请求过来，首先去资源池要求获取一个长连接资源，如果空闲队列里面有长连接，就获取到这个长连接 Socket,并把这个 Socket 移到正在运行的长连接队列。如果空闲队列里面没有，且正在运行的队列长度小于配置的连接池资源的数量，就新建一个长连接到正在运行的队列去，如果正在运行的不下于配置的资源池长度，则这个请求进入到等待队列去。当一个正在运行的 Socket 完成了请求，就从正在运行的队列移到空闲的队列，并触发等待请求队列去获取空闲资源，如果有等待的情况。

下面简单介绍 Node.js 的一个通用连接池模块：generic-pool。

主要文件目录结构